Charlie Garrod Michael Hilton School of Computer Science 15-214 - - PowerPoint PPT Presentation

▶
charlie garrod michael hilton
SMART_READER_LITE
LIVE PREVIEW

Charlie Garrod Michael Hilton School of Computer Science 15-214 - - PowerPoint PPT Presentation

Dec 25, 2022 116 likes •407 views

Architectural Patterns/Styles Charlie Garrod Michael Hilton School of Computer Science 15-214 1 Administrivia Homework 6 checkpoint Monday Dec 4 th Final Exam Review: Dec 13 th , 2-4pm Wean 5409 Final Exam: Dec 15 th ,

slide-1
SLIDE 1

1

15-214

School of Computer Science

Architectural Patterns/Styles

Charlie Garrod Michael Hilton

slide-2
SLIDE 2

2

15-214

Administrivia

  • Homework 6 checkpoint – Monday Dec 4th
  • Final Exam Review: Dec 13th, 2-4pm Wean 5409
  • Final Exam: Dec 15th, 5:30-8:30pm Wean 7500
slide-3
SLIDE 3

3

15-214

Last Time:

  • Design Patterns
slide-4
SLIDE 4

4

15-214

ARCHITECTURAL PATTERNS/STYLES

slide-5
SLIDE 5

5

15-214

Design Patterns

slide-6
SLIDE 6

6

15-214

Architectural Styles

slide-7
SLIDE 7

7

15-214

Architectural Styles

slide-8
SLIDE 8

8

15-214

Architectural Styles vs Design Patterns

slide-9
SLIDE 9

9

15-214

Monolithic Application

+ Simple to start + Simple to deploy + Fast time to first feature

  • Difficult for new developers to come up to speed
  • Continuous deployment is difficult
  • Scaling can be difficult
  • Can devolve into “big ball of mud”
slide-10
SLIDE 10

10

15-214

Layers

slide-11
SLIDE 11

11

15-214

Layers

  • Context:

– A large system that requires decomposition

  • Problem:

– Low separation of concerns. – Parts of system are not interchangeable – Lack of grouped components hurts understandability and maintainability – Lack of boundaries makes tasking difficult

  • Solution:

– Define layers of abstraction – Specify services between boundaries

  • Beware:

– Antipattern: Sinkhole – Antipattern: Lasagna

slide-12
SLIDE 12

12

15-214

Pipe and filter

slide-13
SLIDE 13

13

15-214

Pipe and filter

  • Context:

– Processing data stream

  • Problem:

– Need to process or transform a stream of data – Non-adjacent steps don’t share information – Need to reuse certain steps in the process

  • Solution:

– Each filter transforms the data, then moves it on to the next step

  • Beware:

– Error Handling – Data transformation overhead

slide-14
SLIDE 14

14

15-214

Blackboard

slide-15
SLIDE 15

15

15-214

Blackboard

  • Context:

– An immature domain where no closed approach is known to be feasible

  • Problem:

– A complete search of solution space is not feasable – Multiple algorithms possible for different subtasks – Some algorithms work on the output of others – Uncertain data and aprox solutions are involved

  • Solution:

– Independent programs working cooperatively on common data – Inspect and update data

  • Beware:

– Difficult to test – Difficult establishing a good control strategy

slide-16
SLIDE 16

16

15-214

Model-View-Controller

slide-17
SLIDE 17

17

15-214

Model-View-Controller

  • Context:

– Interactive applications with a flexible Human-Computer interface

  • Problem:

– How to develop an application not dependent on interface – Need ability for application to support different interfaces – Allow simultaneous development

  • Solution:

– Model – View – Controller division

  • Beware:

– Code navigability – Increased complexity

slide-18
SLIDE 18

18

15-214

Broker

slide-19
SLIDE 19

19

15-214

Broker

  • Context:

– Decoupled components interact through remote service invocations

  • Problem:

– Scaling for large scale systems – Components should be decoupled and distributed

  • Solution:

– Brokers mediate between clients and servers

  • Beware:

– Less efficient – Lower fault tolerance

slide-20
SLIDE 20

20

15-214

Microkernel

slide-21
SLIDE 21

21

15-214

Microkernel

  • Context:

– The development of several applications that use similar interfaces on same core

  • Problem:

– Should cope with continuous hardware and software evolution – Platform should be portable, extensible and adaptable

  • Solution:

– Encapsulate fundamental services of your application platform in a microkernel – Other functionality provided by internal servers

  • Beware:

– Complexity of design and implementation

slide-22
SLIDE 22

22

15-214

Event-driven architecture

slide-23
SLIDE 23

23

15-214

Event-driven architecture

  • Context:

– Building a loosely coupled, more responsive system

  • Problem:

– Build a system that reacts to events in the world around it – Only have to decide what to do, not when to do it

  • Solution:

– Event creators, managers, and consumers

  • Beware:

– Security risks – Increased complexity

slide-24
SLIDE 24

24

15-214

Peer-to-peer

slide-25
SLIDE 25

25

15-214

Peer-to-peer

  • Context:

– A system where each node has the same capabilities and responsibilities

  • Problem:

– A situation where it is not feasible to know ahead of time which nodes will be servers – Large amounts of data need to be sent transmitted

  • Solution:

– Decentralized computing – Highly robust in the face of node failure – Highly scalable

  • Beware:

– No server to manage data – No always used for legal purposes

slide-26
SLIDE 26

26

15-214

Service-oriented architecture

slide-27
SLIDE 27

27

15-214

Service-oriented architecture

  • Context:

– Services are provided to other components over a network

  • Problem:

– Building a distributed system – Expose a service no objects

  • Solution:

– Each service should:

  • Represent a business activity with a specific outcome
  • Be self-contained
  • A black-box for its consumers
  • May consist of underlying services
  • Beware:

– High investment cost

slide-28
SLIDE 28

28

15-214

Exercise:

  • Styles:

– Monolith – Layers – Pipe and Filter – Blackboard – MVC – Broker – Peer-to-peer – Microkernel – Event-driven – Service-oriented

  • Application

– Online banking application – API for third party tools to get banking information – Compiler – Optical Character recognition – VR content delivery system – VR game – Insurance claim processing system