University of Toronto Department of Computer Science Lecture

University of Toronto Department of Computer Science Lecture 23: Software Architectures Ü Architectural Styles Ä Pipe and filter Ä Object oriented: Ø Client-Server; Object Broker Ä Event based Ä Layered: Ø Designing Layered Architectures Ä Repositories: Ø Blackboard, MVC Ä Process control © Easterbrook 2004 1

Department of Computer Science University of Toronto Pipe-and-filter Source: Adapted from Shaw & Garlan 1996, p 21 -2. See also van Vliet, 1999 Pp 266 -7 and p 279 filter pipe pipe Ü pipe filter pipe Examples: Ä UNIX shell commands Ä Compilers: Ø Lexical Analysis -> parsing -> semantic analysis -> code generation Ä Signal Processing Ü Interesting properties: Ä filters don’t need to know anything about what they are connected to Ä filters can be implemented in parallel Ä behaviour of the system is the composition of behaviour of the filters Ø specialized analysis such as throughput and deadlock analysis is possible © Easterbrook 2004 2

Department of Computer Science University of Toronto Object Oriented Architectures Source: Adapted from Shaw & Garlan 1996, p 22 -3. method invocation object Examples: object method invocation Ü object method invocation Ä abstract data types Ü Interesting properties Ä data hiding (internal data representations are not visible to clients) Ä can decompose problems into sets of interacting agents Ä can be multi-threaded or single thread Ü Disadvantages Ä objects must know the identity of objects they wish to interact with © Easterbrook 2004 3

Department of Computer Science University of Toronto Variant 1: Client Server client method invocation Server Ü method invocation Interesting properties Ä Is a special case of the previous pattern object oriented architecture Ä Clients do not need to know about one another Ü Disadvantages Ä Client objects must know the identity of the server © Easterbrook 2004 4

Department of Computer Science University of Toronto Variant 2: Object Brokers client broker server client Ü Interesting properties Ä Adds a broker between the clients and servers Ä Clients no longer need to know which server they are using Ä Can have many brokers, many servers. Ü Disadvantages Ä Broker can become a bottleneck Ä Degraded performance © Easterbrook 2004 5

University of Toronto Department of Computer Science Broker Architecture Example © Easterbrook 2004 6

Department of Computer Science University of Toronto Event based (implicit invocation) Source: Adapted from Shaw & Garlan 1996, p 23 -4. See also van Vliet, 1999 Pp 264 -5 and p 278 announce event agent broadcast medium agent Ü Examples listen for event announce event agent Ä debugging systems (listen for particular breakpoints) Ä database management systems (for data integrity checking) Ä graphical user interfaces Ü Interesting properties Ä announcers of events don’t need to know who will handle the event Ä Supports re-use, and evolution of systems (add new agents easily) Ü Disadvantages Ä Components have no control over ordering of computations © Easterbrook 2004 7

Department of Computer Science University of Toronto Layered Systems Source: Adapted from Shaw & Garlan 1996, p 25. See also van Vliet, 1999, p 281. application layer utilities users Ü kernal Examples Ä Operating Systems Ä communication protocols Ü Interesting properties Ä Support increasing levels of abstraction during design Ä Support enhancement (add functionality) and re-use Ä can define standard layer interfaces Ü Disadvantages Ä May not be able to identify (clean) layers © Easterbrook 2004 8

Department of Computer Science University of Toronto Variant: 3 -layer data access Presentation layer Appl’n Views Java AWT Application Logic layer Business logic Contol objects File Mgmnt Query Engine © Easterbrook 2004 DBMS Storage layer 9

University of Toronto Department of Computer Science Open vs. Closed Layered Architecture Ü closed architecture Ä each layer only uses services of the layer immediately below; Ä Minimizes dependencies between layers and reduces the impact of a change. Layer N-1 Layer 2 Layer 1 Ü open architecture Ä a layer can use services from any lower layer. Ä More compact code, as the services of lower layers can be accessed directly Ä Breaks the encapsulation of layers, so increase dependencies between layers Layer N-1 Layer 2 Layer 1 © Easterbrook 2004 10

Department of Computer Science University of Toronto How many layers? Ü Ä application layer Ä database layer Ä e. g. simple client-server model Ü Application (client) 2 -layers: 3 -layers: Database (server) Presentation layer (user interface) Business Logic Ä separate out the business logic Øhelps to make both user interface and database layers modifiable Ü 4 -layers: Ä Separates applications from the domain entities that they use: Database Presentation layer (user interface) Applications Øboundary classes in presentation layer Øcontrol classes in application layer Øentity classes in domain layer Ü Domain Entities Database Partitioned 4 -layers Ä identify separate applications UI 1 UI 2 UI 3 UI 4 App 1 App 2 App 3 App 4 Domain Entities Database © Easterbrook 2004 11

Department of Computer Science University of Toronto Repositories Source: Adapted from Shaw & Garlan 1996, p 26 -7. See also van Vliet, 1999, p 280 agent Ü Examples blackboard (shared data) agent Ä databases Ä blackboard expert systems Ä programming environments Ü Interesting properties Ä can choose where the locus of control is (agents, blackboard, both) Ä reduce the need to duplicate complex data Ü Disadvantages Ä blackboard becomes a bottleneck © Easterbrook 2004 12

Department of Computer Science University of Toronto Variant: Model-View-Controller propagate update controller update access model controller access view Ü propagate Properties Ä One central model, many views (viewers) Ä Each view has an associated controller Ä The controller handles updates from the user of the view Ä Changes to the model are propagated to all the views © Easterbrook 2004 13

University of Toronto Department of Computer Science Model View Controller Example © Easterbrook 2004 14

University of Toronto Department of Computer Science MVC Component Interaction © Easterbrook 2004 15

Department of Computer Science University of Toronto Process Control Source: Adapted from Shaw & Garlan 1996, p 27 -31. input variables control parameters Ü controller manipulated variables Examples s or s en s process actuators controlled variables Ä aircraft/spacecraft flight control systems Ä controllers for industrial production lines, power stations, etc. Ä chemical engineering Ü Interesting properties Ä separates control policy from the controlled process Ä handles real-time, reactive computations Ü Disadvantages Ä Difficult to specify the timing characteristics and response to disturbances © Easterbrook 2004 16