Composition vs. Inheritance, Cloud Computing, and REST-based - - PowerPoint PPT Presentation

▶
composition vs inheritance cloud computing and rest based
SMART_READER_LITE
LIVE PREVIEW

Composition vs. Inheritance, Cloud Computing, and REST-based - - PowerPoint PPT Presentation

Jan 30, 2024 28 likes •289 views

Material and some slide content from: - Atif Kahn SERVICES COMPONENTS OBJECTS MODULES Composition vs. Inheritance, Cloud Computing, and REST-based Architectures Reid Holmes Store Example Starbucks example Beverages: house, dark

slide-1
SLIDE 1

Material and some slide content from:

  • Atif Kahn
  • Composition vs. Inheritance,

Cloud Computing, and REST-based Architectures

Reid Holmes

OBJECTS MODULES SERVICES COMPONENTS

slide-2
SLIDE 2

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Store Example

  • Starbucks example
  • Beverages: house, dark
  • Toppings: whip, milk
  • Each beverage needs a cost() function
  • Build class diagram for this system
slide-3
SLIDE 3

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Store Example

  • Starbucks example
  • Beverages: house, dark, decaf, espresso
  • Toppings: whip, milk, soy, mocha, unicorn tears
  • Each beverage needs a cost() function
  • Build class diagram for this system
slide-4
SLIDE 4

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Decorator

  • Intent: “Dynamically add additional responsibilities to

structures.”

  • Motivation: Sometimes we want to add new

responsibilities to individual objects, not the whole

  • class. Can enclose existing objects with another
  • bject.
  • Applicability:
  • Add responsibilities dynamically and transparently.
  • Remove responsibilities dynamically.
  • When subclassing is impractical.
slide-5
SLIDE 5

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Decorator

  • Structure
  • Participants:
  • Component / concrete component
  • Decorator / concrete decorator
slide-6
SLIDE 6

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Decorator (code ex)

// the Window interface interface Window { public void draw(); // draws the Window public String getDescription(); }

  • // implementation of a simple Window

class SimpleWindow implements Window { public void draw() { // draw window }

  • public String getDescription() {

return "simple window"; } } // abstract decorator class abstract class WindowDecorator implements Window { protected Window decoratedWindow;

  • public WindowDecorator (Window decoratedWindow) {

this.decoratedWindow = decoratedWindow; } public void draw() { decoratedWindow.draw(); } }

  • // adds vertical scrollbar functionality

class VerticalScrollBarDecorator extends WindowDecorator { public VerticalScrollBarDecorator (Window decoratedWindow) { super(decoratedWindow); } public void draw() { drawVerticalScrollBar(); super.draw(); } private void drawVerticalScrollBar() { .. } public String getDescription() { return decoratedWindow.getDescription() +" and vert sb"; } } // adds horizontal scrollbar functionality class HorizontalScrollBarDecorator extends WindowDecorator { public HorizontalScrollBarDecorator (Window decoratedWindow) { super(decoratedWindow); } public void draw() { drawHorizontalScrollBar(); super.draw(); } private void drawHorizontalScrollBar() { .. } public String getDescription() { return decoratedWindow.getDescription() + "and horiz sb"; } } public class DecoratedWindowTest { public static void main(String[] args) { Window decoratedWindow = new HorizontalScrollBarDecorator ( new VerticalScrollBarDecorator(new SimpleWindow())); // print the Window's description System.out.println(decoratedWindow.getDescription());}}

slide-7
SLIDE 7

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Decorator

  • Collaborations
  • Decorators forward requests to component object.
  • Consequences:
  • More flexible.
  • (than static inheritance; arbitrary nesting possible)
  • Avoids feature-laden classes.
  • (KISS and add functionality as needed.)
  • Warn: Decorator & component are not identical.
  • (equality can be thrown off because decorator != decorated)
  • Negative: Many of little objects.
  • (Lots of small, similar-looking classes differentiated by how

they are connected. hard to understand and debug.)

slide-8
SLIDE 8

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Decorator

  • Implementation:
  • 1) Interface conformance. (decorator interface required)
  • 2) Abstract decorator not needed if only one

decoration is required.

  • 2) Keep component classes lightweight. (too

heavyweight can overwhelm decorators

  • 3) Changing a skin instead of changing the guts.

(if component is heavy, consider strategy instead)

  • Related to: Decorators are a kind of single-node
  • Composite. Decorators can change the skin,

Strategy pattern can change the guts.

slide-9
SLIDE 9

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Decorator (io ex)

new File(“446.csv”);

slide-10
SLIDE 10

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Decorator (io ex)

new FileInputStream( new File(“446.csv”));

slide-11
SLIDE 11

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Decorator (io ex)

new BufferedInputStream( new FileInputStream( new File(“446.csv”) ));

slide-12
SLIDE 12

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Decorator (io ex)

new LineNumberInputStream( new BufferedInputStream( new FileInputStream( new File(“446.csv”) )));

slide-13
SLIDE 13

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Composition vs Inheritance

  • Has-a relationships are more flexible than is-a
  • With composition:
  • Behaviour can be extended by dynamically
  • Provides natural extension points
  • Comprehension challenges (many small classes)
  • Delegation can impact performance
  • With inheritance:
  • Subclasses ‘reuse’ superclass code
  • Changing parent types can cause large changes

in client code

  • Supertype changes can impact all subtypes
slide-14
SLIDE 14

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Cloud precursors

  • Grid Computing:
  • Combination of computing resources from

multiple administrative domains applied to common tasks.

  • Usually used to create ‘super computers’ that

can work on specific parallel computation tasks.

  • Utility Computing:
  • Combining computation, storage, and services

metered like utilities.

slide-15
SLIDE 15

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Cloud Computing

  • “Cloud computing is a model for enabling

convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.” [NIST]

slide-16
SLIDE 16

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

NIST Essential Characteristics

  • On-demand self-service:
  • Consumers can provision computing capabilities

without human interaction.

  • Broad network access:
  • Capabilities are available over the network

through standard mechanisms.

  • Resource pooling:
  • Computing resources are pooled to serve

multiple consumers.

  • Location independence. [perfomance/security]
slide-17
SLIDE 17

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

NIST Essential Characteristics

  • Rapid elasticity
  • Resources can be easily added and removed.
  • Measured service [services and/or resources]
  • Metering of storage, processing, bandwidth, etc.
slide-18
SLIDE 18

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Benefits

  • Agility [quickly respond to changes]
  • Scalability [resources can be added, peak load]
  • Cost [resources can be released; multi-tenancy (amortization)]
  • Reliability [different sites, experts in control]
  • Security [works both ways]
slide-19
SLIDE 19

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Technology

  • Thick and thin clients
  • Broadband
  • Data centres
  • Large capacity
  • Globally distributed
  • APIs
  • Administration
  • Development
  • Resource migration
slide-20
SLIDE 20

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Virtualization

  • Virtualization [decoupling physical & computing resources]
  • Emulation (QEMU) [VM simulates partial HW]
  • Paravirtualization (Xen) [SW int to VM]
  • Full (VMWare) [complete sim of HW]
  • Network [abstract network e.g., VPNs]
slide-21
SLIDE 21

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Cloud Layers

  • SaaS (e.g., Google Docs) [multi-tenancy, single release for all users]
  • Vendor-controlled remote applications.
  • Concerns: control, performance, security, privacy.
  • PaaS (e.g., AppEngine)
  • Vendor-controlled environment.
  • Concerns: as for SaaS w/ limited technology choices.
  • IaaS (e.g., Amazon EC2)
  • Vendor-provided resources; consumer provisions VM.
  • Concerns: more expertise needed to leverage flexibility.
slide-22
SLIDE 22

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Cloud Spectrum

slide-23
SLIDE 23

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Layers of Control

!"#$%&' (#%&)*" ("&+"& ,- .// 0)#) !"#$%&' (#%&)*" ("&+"& ,- .// 0)#) !"#$%&' (#%&)*" ("&+"& ,- .// 0)#) !"#$%&' (#%&)*" ("&+"& ("&+12"3 .// 0)#) !"#$%&' (#%&)*" ("&+"& ("&+12"3 .// 0)#) 4&*)516)#1%5 2%5#&%77"8 4&*)516)#1%59:93"&+12"9 ;&%+18"&93<)&"92%5#&%7 ("&+12"9/&%+18"& 2%5#&%77"8 =5><%?3"

0";7%@A"5#

B%3#"8

0";7%@A"5#

=))(

C7%?8

/))(

C7%?8

())(

C7%?8

DEF9!"#$%&"'"()*+,-*./$(0%1"-#*/2*3/(+1/&*"(*+,-*3&/$04*5-6*78894* <##;GHH'32%##A%&&13%5I2%AHJKKLHEJHKEH+13?)71615*>#<">M%?58)&1"3>%N>2%5#&%7>15>#<">27%?8H

slide-24
SLIDE 24

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Cloud Security NFPs

  • Users want assurances of:
  • Confidentiality [keep unauthorized users out]
  • Integrity [data has not altered]
  • Authenticity [data provenance]
  • Anonymity [users are unidentifiable]
  • Privacy [user data is properly controlled]
  • Data remanence is problematic:
  • How can you purge data from the cloud?
slide-25
SLIDE 25

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

REST

  • Representational state transfer (REST)
  • Key constraints:
  • Client/server
  • Servers to not maintain session state
  • Clients must not depend on direct server access
  • Clients communicate using a uniform interface
  • e.g., URIs and self-descriptive payloads
slide-26
SLIDE 26

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

REST Operations

  • Four main operations: GET, POST, PUT, DELETE
  • Operation can change functionality:
  • GET /resources/ —> list resources
  • PUT /resources/ —> replace resources
  • POST /resources/ —> append to resources
  • DELETE /resources/ —> delete resources
  • URIs are often versioned:
  • /api/v2.0/list/
  • /api/v3.0/list/
  • REST endpoints enable direct testing:
  • e.g., curl --include https://api.github.com/users/rtholmes