CISC 323 (Week 11) Due Date: Thursday, April 7, 2005 (3:00pm) - - PowerPoint PPT Presentation

CISC 323 (Week 11) Architectural Styles

Jeremy Bradbury Teaching Assistant March 30, 2005 bradbury@cs.queensu.ca

March 30, 2005 Jeremy Bradbury (CISC 323)

Assignment #5

Due Date: Thursday, April 7, 2005 (3:00pm) The only task: Write a complete CD catalog

program with editing features, following your design from Assignment 4.

You may re-use any code you wish from Assignments

1 and 2 -- your own code and/or code posted as a solution.

If you encounter design problems…

It is quite possible that you will find problems in your design

from Assignment 4. You may have left something out, or you may find that a particular method would be easier to use and/or implement if its parameters were different. In the real world, you would ideally go back and fix your design. For this assignment, you may instead list for us the ways your implementation disagrees with your design and why you made these decisions.

March 30, 2005 Jeremy Bradbury (CISC 323)

Assignment #5

Marking Scheme: This assignment is worth a total of

20 marks. Correctness: 14 Follows Design: 3 Style: 3

For incomplete programs, the correctness points will

be broken down as follows:

change basic CD information (title, composer, performer, tag): 3 delete a CD: 2 change track information (title, composer, performer): 3 delete a track from a CD: 2 add a new track to a CD: 2 add a new CD to a catalog: 2

March 30, 2005 Jeremy Bradbury (CISC 323)

Architectural Styles

Client-Server Pipe and Filter Layers Event-based (Implicit Invocation) Repository Data Abstraction and Object-Oriented

Organization

March 30, 2005 Jeremy Bradbury (CISC 323)

Past Midterm/Exam Questions

Question 1, Midterm 2002 (5 pts): What is

the difference between a design pattern and an architectural style?

(Note this question was also on the Final in 2003 and worth 3 pts)

March 30, 2005 Jeremy Bradbury (CISC 323)

Past Midterm/Exam Questions

Answer: The difference is the scale or level at which

they are applied.

A design pattern describes a relationship between

individual classes to solve a small problem inside a larger system. Design patterns are also called micro- architectures.

An architectural style is a way of breaking up a large

system into subsystems or components, each of which may contain multiple classes.

Each component in a system may use one or more

design patterns to structure the relationships between the classes in the component.

March 30, 2005 Jeremy Bradbury (CISC 323)

Client-Server Architectural Style

Components: Servers and clients Constraints: requests only sent by clients and

responses only sent by servers

Examples: WWW

Clients: Browsers Servers: Web servers

Email

Clients: Programs to read and write email (Outlook, mail, pine,

Eudora)

Servers: “Mail-drop” machine that

March 30, 2005 Jeremy Bradbury (CISC 323)

Pipe and Filter Architectural Style

Components: Set of data filters Connectors/interaction: Data is passed from one

filter to the next via pipes

Constraints: Data is passed in sequence from one

filter to the next

March 30, 2005 Jeremy Bradbury (CISC 323)

Pipe and Filter Architectural Style

Example: compiler

March 30, 2005 Jeremy Bradbury (CISC 323)

Past Midterm/Exam Questions

Question 6, Midterm 2002 (10 pts): From

the lecture material, describe two types of changes that are very easy to make when using the pipe-and-filter architectural style. Describe a type of change that is very difficult to make when using the pipe-and-filter architectural style.

(Note: Students in 2002 also had an assignment on pipe-and-filter)

March 30, 2005 Jeremy Bradbury (CISC 323)

Past Midterm/Exam Questions

Solution: Most common valid answers: Easy Change: Add a new filter, since this

requires only changes to two connectors.

Easy Change: Modify an existing filter, so long

as the input and output data formats are unaffected.

Difficult Change: Modify the data structure

(format), since it can potentially affect every filter in the system.

March 30, 2005 Jeremy Bradbury (CISC 323)

Layered Architectural Style

Components: the layers Connectors/interactions: Protocols

for communication between layers

Constraints: Each component allowed

to use services in interface of layer below it. Provides interface to layer above it.

Domain: Whenever problem can be

decomposed into sequence of layers each with strong cohesion

March 30, 2005 Jeremy Bradbury (CISC 323)

Layered Architectural Style

Example: web browser

March 30, 2005 Jeremy Bradbury (CISC 323)

Past Midterm/Exam Questions

Question 5, Final 2003 (6 pts): You have been

given a badly-written software system to update. You decide to re-write it completely and to use a Layered architectural style. How will your new system compare to the old system with regards to the following three attributes? Coupling, Performance (time), and Modifiability.

For example, would you expect your new system to

have higher or lower coupling than the old system and why? Please restrict yourself to one or two sentences for each attribute.

March 30, 2005 Jeremy Bradbury (CISC 323)

Past Midterm/Exam Questions

Solution: Coupling: Lower because components only

communicate with the components directly above and below.

Performance (time): Greater time required

because components can only interact with adjacent components.

Modifiability: Higher because only adjacent

components are directly dependent on any given component.

March 30, 2005 Jeremy Bradbury (CISC 323)

Past Midterm/Exam Questions

Question 1.2, Final 2002 (5 points): When we

discussed the layered architectural style in class, we focused on a strict layering approach (layers can only interact with the layers directly above and below them). In many real systems, the layered architecture breaks down, with method calls often bypassing one or more layers. Briefly explain one (1) reason why developers may choose to do this, and one (1) reason why this is a bad idea.

March 30, 2005 Jeremy Bradbury (CISC 323)

Past Midterm/Exam Questions

Solution: One reason why developers may choose to do

this: Performance

One reason why this is a bad idea: high

coupling or decreased modifiability

March 30, 2005 Jeremy Bradbury (CISC 323)

Event-based Architectural Style (Implicit Invocation)

Components: send and subscribe to events Connectors/interaction: event connector (a.k.a

dispatcher) keeps track of:

which components are interested in which events which method m in an interested component C is to

be invoked upon the announcement of an event e by storing a set of bindings (e, C, m)

Constraints: Announcing components do not know

who will receive their events (anonymity), in which

• rder events will be delivered, or what receiving

components will do in response.

March 30, 2005 Jeremy Bradbury (CISC 323)

Event-based Architectural Style (Implicit Invocation)

Example: a program development environment.

March 30, 2005 Jeremy Bradbury (CISC 323)

Repository Architectural Style

Components: a central data

structure (repository)

• represents (parts of) state

information that is to be shared

• components have direct access to

it

• e.g.: data bases, files, shared

memory components that access repository

Connector/interactions:

• components can invoke each
• ther
• components read/write

information from/to repository

• repository passive

March 30, 2005 Jeremy Bradbury (CISC 323)

Repository Architectural Style

Example: Compiler with pipe and filter and

repository

March 30, 2005 Jeremy Bradbury (CISC 323)

Past Midterm/Exam Questions

Question 1, Midterm 2002 (5 pts): Describe

the difference between the pipe-and-filter architectural style and the repository architectural style.

(Note this question was also on the Final in 2003 and worth 3 pts)

March 30, 2005 Jeremy Bradbury (CISC 323)

Past Midterm/Exam Questions

Solution: In a pipe-and-filter architecture, each filter operates on the data

• sequentially. Each filter reads one or more stream of data and
• utputs one or more streams of data – maybe in the same

format(s) or maybe in different formats. The only communication between the components (filters) is the data streams passing between them.

In a repository architecture, there is a common pool of data in a

fixed format. All of the components access and modify this data. They don't necessarily do this sequentially.

The main point is data streams passing through filters vs. a

shared pool of data.