[PPT] - CISC 323 Intro to Software Engineering Example: Marks management PowerPoint Presentation

SLIDE 1

CISC 323 Intro to Software Engineering

Topic 7: Software Architecture

Subtopics:

Client-Server
Pipe and Filter
Layers
Event-based, Implicit Invocation
Repository
Data Abstraction and Object Orientation
Case studies: instrumentation software, mobile

robotics (time permitting)

CISC 323, Winter 2004, Software Architecture 2

Client-Server Architectural Style

Example: Marks management system

✁

Components: Servers and clients

✁

Constraints:

✂

requests only sent by clients

✂

responses only sent by servers

CISC 323, Winter 2004, Software Architecture 3

Client-Server: Connectors/Interaction

✄

Typically,

disconnect send message disconnect send reply listen for connections stop listening connect Client 2 send message connect Client 1 Server Source: Object-oriented Software Engineering. Lethbridge and Laganiere. 2001 CISC 323, Winter 2004, Software Architecture 4

Client-Server: Domain

☎

Client-Server most appropriate when it is natural to implement a set of services in a fixed, central location

☎

Peer-to-peer

✆

special case of client-server system

✆

each component can be both a client and a server to the other components

SLIDE 2

CISC 323, Winter 2004, Software Architecture 5

Client-Server: Properties

✝

In general and if used appropriately and implemented correctly,

✞

high cohesion and low coupling

✞

high readability and reusability

✟

Potential problem areas:

✞

Modifiability

✠

change to server may require changes to all clients

✡

Availability

✠

if server goes down, whole system may stop working

✡

Performance

✠

connection between client and server may be bottleneck

✡

Security

✠

communication may be eavesdropped

CISC 323, Winter 2004, Software Architecture 6

Client-Server: More Examples

☛

Client-server systems are very common

☛

Examples:

☞

WWW

✌

Clients: Browsers

✌

Servers: Web servers

☞

Email

✌

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

✌

Servers: “Mail-drop” machine that

✍

holds incoming email until contacted by client

✍

forwards outgoing email

✎

Database systems

✏

Clients: Application program using database (e.g., through JDBC)

✏

Server: Database management system (e.g., DB2)

CISC 323, Winter 2004, Software Architecture 7

Architectural Styles: Roadmap

✑

Client-Server (done)

✑

Pipe and Filter (next)

✑

Layered Systems

✑

Event-Based, Implicit Invocation

✑

Repositories

✑

Data Abstraction and Object Organization

CISC 323, Winter 2004, Software Architecture 8

Pipes and Filters Architecture 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

Filters Pipes

SLIDE 3

CISC 323, Winter 2004, Software Architecture 9

Pipe and Filter: Example

✔

Compiler architecture

✕

Compilers map program text (e.g., Java text files) into executable code (e.g., Java byte code, or “.exe” file containing INTEL x86 code)

✕

This is too complex to do all at once. To simplify structure, pipe and filter architecture often used

Scanner Parser Semantic Analyzer Code Generator program text executable code

CISC 323, Winter 2004, Software Architecture 10

Step 1 in Compiling: Scanning

✖

Turn program text into a sequence of tokens

✖

Tokens:

✗

represent keywords of language (e.g., if, while, static)

✗

may store/contain values (e.g., tInt stores integers)

✖

For example:

if (x==3) { … } 32 * (2 + 100)

might become

tIf tLeftP tIdentifer “x” tEqEq tInt 3 tRightP tLeftB … tRightB tInt 32 multiply lparen tInt 2 plus tInt 100 rparen

CISC 323, Winter 2004, Software Architecture 11

Step 2 in Compiling: Parsing

✘

Check syntax of input …

✙

For example,

✚

in Java, the following programs generate syntax errors

✛

if {x==10} … // {…} instead of (…)

✛

while (true) {x = x+1} // ; missing

✛

if (x=1) {…}

✜

… by building parse tree

CISC 323, Winter 2004, Software Architecture 12

Step 2 in Compiling: Parsing (Cont’d)

For instance, the Java program

if (x == 10) y = 2; else z = z + 4;

gets parsed into the following tree:

if == x 10 = y 2 = z + z 2

SLIDE 4

CISC 323, Winter 2004, Software Architecture 13

Steps 3 and 4 in Compiling: Semantic Analysis and Code Generation

✢

Semantic analysis

✣

Check context-sensitive syntax

✤

E.g., variables have been declared, types are ok

✢

Code generation

✣

Create native code from parse tree

CISC 323, Winter 2004, Software Architecture 14

Compiling as Pipe and Filter Architecture

Scanner Parser Semantic Analyzer Code Generator

program text executable code tokens parse tree parse tree

CISC 323, Winter 2004, Software Architecture 15

Pipe and Filter: Domain

✥

The Pipe and Filter style is most appropriate when

✦

The problem can be naturally divided into a sequence of processing steps over some data stream

✦

The format of the data being passed can be described in a simple and precise manner

CISC 323, Winter 2004, Software Architecture 16

Pipe and Filter: Properties

✧

In general and if used appropriately and implemented correctly,

★

high cohesion and low coupling

★

high readability and reusability

✧

Potential problem areas:

★

Modifiability

✩

change may impact several filters

★

Performance

✩

connection between filters may be bottleneck

★

Availability

✩

if one filter goes down, whole system may stop working

★

Security

✩

communication may be eavesdropped

SLIDE 5

CISC 323, Winter 2004, Software Architecture 17

Properties of Pipe and Filter: Modifiability

✪

Modifications to system may impact three areas

✫

Change filter:

✬

For example, implement faster scanning algorithm

✬

Change localized to filter itself, which is good

✫

Change format of data passed between filters:

✬

For example, add a new token or change parse tree format

✬

Expensive, since (at least) two filters impacted by change

✫

Add a new filter:

✬

inexpensive if data format not impacted

✪

Therefore, Pipe and Filter offers good modifiability if data format stable

CISC 323, Winter 2004, Software Architecture 18

Example: Adding an Optimizer to the Compiler

Scanner Parser Semantic Analyzer Code Generator

program text executable code tokens parse tree parse tree

CISC 323, Winter 2004, Software Architecture 19

Example: Adding an Optimizer to the Compiler (Cont’d)

✭

Source-level optimizer improves source code

✮

For example,

x = 3; y = x+1; if (y+1 < 10) {c1} else {c2}

is improved to

x = 3; y = 4; c1

✭

Code-level optimizer improves executable code

CISC 323, Winter 2004, Software Architecture 20

Example: Adding an Optimizer to the Compiler (Cont’d)

Scanner Parser Semantic Analyzer Code Generator

program text executable code tokens parse tree parse tree

Source-level Optimizer

parse tree

SLIDE 6

CISC 323, Winter 2004, Software Architecture 21

Example: Adding an Optimizer to the Compiler (Cont’d)

Scanner Parser Semantic Analyzer Code Generator

program text executable code tokens parse tree parse tree

Source-level Optimizer

parse tree

Code Optimizer

executable code

CISC 323, Winter 2004, Software Architecture 22

Properties of Pipe and Filter: Performance

✯

Some opportunity for parallel processing

✰

Run each filter on a different processor

✰

Only works if filters work incrementally, that is, if filters are not obliged to wait for preceding filter to complete its work before starting themselves

✰

Performance gains will only be significant if parallel filters each perform significant work

CISC 323, Winter 2004, Software Architecture 23

Let t1,…tn be time to compute each filter f1,…fn Let s1,…sn-1 be time to move data over pipes p1,…pn-1 Then execution time in the sequential case is

Properties of Pipe and Filter: Performance (Cont’d)

✱

Simple model to analyze parallel performance:

f1 f2 fn

…

p1 p2 pn-1

Simplifying assumption: all filters are able to start processing data at the same time. Can you think of cases where this might not be true?

i=1 n i=1 n-1

∑ti + ∑si

n-1 i=1 i=1 n

max ti + ∑si

and execution time in the parallel case is

CISC 323, Winter 2004, Software Architecture 24

Properties of Pipe and Filter: Performance (Cont’d)

✲

Some optimizations may be lost by strict decomposition into filters

✲

There may be some overhead of creating similar data structures from streams provided by pipes

✳

E.g.,

✴

parser creates parse tree

✴

turns parse tree into token stream to send over pipe

✴

semantic analyzer recreates parse tree from token stream

SLIDE 7

CISC 323, Winter 2004, Software Architecture 25

Architectural Styles: Roadmap

✵

Client-Server (done)

✵

Pipe and Filter (done)

✵

Layered Systems (next)

✵

Event-Based, Implicit Invocation

✵

Repositories

✵

Data Abstraction and Object Organization

CISC 323, Winter 2004, Software Architecture 26

Layers Architecture 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

Layer 1 Layer 2 Layer n

CISC 323, Winter 2004, Software Architecture

27

Layered: Example 1

✸

The Unified Approach advocates the use of a layered architecture

User Interface (View) Layer: for user interaction

Data Workstation

Owner Name Title Address

Business Layer: for computation Access Layer: for retrieval and storage

CISC 323, Winter 2004, Software Architecture 28

Layered: Example 2 (Web Browsing)

Web Browser

HTTP Server

HTTP Request

(e.g. http://www.cs.queensu.ca/~cisc322)

HTML Document

1. Web Browser issues HTTP Request (a string)
2. HTTP Server responds with HTML Document (also a

string)

3. Web Browser renders HTML Document as a web page

SLIDE 8

Example HTTP Document

<h2>Text</h2> The course text is: <ul>Bernd Oestereich, Developing Software with UML, Addison-Wesley, 1999</ul> For those interested in further reading, I recommend: <blockquote>Len Bass, Paul Clements and Rick Kazman, Software Architecture in Practice, Addison-Wesley, 1998 Mary Shaw and David Garlan, Software Architecture: Perspectives

n

an Emerging Discipline, Prentice Hall, 1996 Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements of Reusable Object- Oriented Software, Addison-Wesley, 1995</blockquote>

A fragment of an HTML document and how it looks in a browser

CISC 323, Winter 2004, Software Architecture 30

Web Browsing as a Layered Architecture

HTML Browser TCP IP IEEE 802.3 HTML Server TCP IP IEEE 802.3

connect, send string send datagram send frame accept connection, receive string receive datagram receive frame

Protocol Stack

CISC 323, Winter 2004, Software Architecture 31

Web Browsing as a Layered Architecture (Cont’d)

✹

Layers in protocol stack communicate by …

✺

providing services/information to layer above

✺

calling layer below for lower level services/information

… such that …

✺

layers provide increasingly abstract view of the network, that is, the higher the layer, the more abstract the view, and

✺

layers encapsulate functionality that can be plug- replaced

Link Layer

✻

Interfaces directly with hardware, e.g., device drivers

✻

May use different protocols, e.g.:

✼

IEEE 802.3 protocol for Ethernet

✼

PPP for modems

✻

Offers:

✼

direct sending and receiving of packets/frames between machines in the same network

✼

delivery not guaranteed:

✽

Sent packets/frames may or may not arrive

✼

encapsulates access to specific hardware HTML Browser TCP IP IEEE 802.3

connect, send string send datagram send frame accept connection, receive string receive datagram receive frame

SLIDE 9

Internet Protocol Layer

Internet protocol (IP) offers:

✾

datagram abstraction: header, address, data

✾

perations to send/receive

datagrams

✾

delivery still not guaranteed

✿

e.g., IP discards corrupted datagrams

✾

routing:

✿

like a letter, datagram requires address, but doesn’t have to be in same network

✿

routers figure out how to pass datagrams between networks HTML Browser TCP IP IEEE 802.3

connect, send string send datagram send frame accept connection, receive string receive datagram receive frame

CISC 323, Winter 2004, Software Architecture 34

IP Datagram (simplified)

Protocol version number Header checksum IP Address Data Protocol generating this datagram - e.g., TCP Check that header arrived safely Where packet is to be sent - e.g., bilbo.caslab.queensu.ca (127.15.1.26) The actual data being transmitted - e.g., an HTML page

Transport Layer

Transmission control protocol (TCP) offers:

❀

socket connections: like notion

f dialing a telephone,

establishes a connection between two parties over which data can be sent

❀

send/receive: operations to send/receive a string value

❀

guaranteed, reliable delivery:

If browser sends string “www.cs.queensu.ca”, receiver receives exactly this string HTML Browser TCP IP IEEE 802.3

connect, send string send datagram send frame accept connection, receive string receive datagram receive frame

CISC 323, Winter 2004, Software Architecture 36

TCP

❁

TCP breaks messages into set of IP datagrams

❂

Adds address to each datagram

❁

Verifies that all datagrams arrive

❂

Resents if necessary

❂

Discards duplicates

❁

When message completely reassembled, makes available to application layer (e.g., HTTP browser)

SLIDE 10

Summary

❃

Each layer presents a different abstraction of the network

❃

Higher-level layers make the network easier to use

❄

IP: routing

❄

TCP: guaranteed delivery

❃

Each layer

❄

provides services to layer above it

❄

uses services in layer below it

❄

encapsulates a certain set of services HTML Browser TCP IP IEEE 802.3

connect, send string send datagram send frame accept connection, receive string receive datagram receive frame

CISC 323, Winter 2004, Software Architecture 38

Performance of Layered Style

Observations:

❅

When developing layer k

❆

can only use services of layer k-1 (=> low coupling)

❆

nly need to implement services for layer k+1 (=> high cohesion)

⇒ good readability and modifiability

❅

But, strict layering can mean loss in performance (e.g., it’s possible that lower layers have services that allow improved performance)

❅

Therefore, trade off advantages in coupling, modifiability versus possible performance issues

CISC 323, Winter 2004, Software Architecture 39

Performance Example

❇

Imagine want to transmit audio/video data

❇

Video frames encoded as messages sent via TCP

❈

E.g., MPEG, Motion JPEG, AVI, QuickTime,…

❇

Transmission can “jitter” (high variance in reception of packets) due to

❈

retries if frames are lost video lost

❈

ther network traffic

❇

For video, better to have slightly “lossy” protocol where some frames may be lost, but frames can be arrive at a constant rate (low “jitter”)

❇

Change protocol stack accordingly

Video Server Video Player

CISC 323, Winter 2004, Software Architecture 40

Modifiability of Layered Style

❉

If layer k changed internally

❊

No impact on other layers

❉

If interface/services provided by layer k change

❊

Impact limited to layer k-1

❊

I.e., only layer using layer k may have to change

Layer 1 Layer 2 Layer n

SLIDE 11

CISC 323, Winter 2004, Software Architecture 41

Modifiability Questions

❋

If you are considering implementing a system based

n layers, need to ask
What are likely modifications?
Can these modifications be confined to the layers?
Do they require changes to multiple layers?

CISC 323, Winter 2004, Software Architecture 42

Properties of Layered Architecture

❍

In general and if used appropriately and implemented correctly,

■

high cohesion and low coupling

■

high readability and (potentially) reusability

❍

Potential problem areas

■

Availability

❏

if one layer malfunctions, whole system might malfunction

■

Performance

❏

bypass layers to trade off coupling and readability for performance

■

Modifiability

❏

change might require several layers to be modified

CISC 323, Winter 2004, Software Architecture 43

Architectural Styles: Roadmap

❑

Client-Server (done)

❑

Pipe and Filter (done)

❑

Layered Systems (done)

❑

Event-Based/Implicit Invocation (aka, Publish- Subscribe) (next)

❑

Repositories

❑

Data Abstraction and Object Organization

CISC 323, Winter 2004, Software Architecture 44

Event-Based/Implicit Invocation

▲

Components interact by announcing (raising) and receiving events

▲

Events:

▼

indicate that something interesting has happened

▼

can carry data

▼

for example:

◆

mouse click, button pressed, menu item selected, text input

◆

debit card inserted

◆

5th login attempt failed

SLIDE 12

CISC 323, Winter 2004, Software Architecture 45

Event Connector (Dispatcher)

❖

Components do not send events directly to interested components, but send them to event connector instead

❖

Event connector (also called dispatcher)

P

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

P

by storing a set of bindings (e, C, m)

❖

Component can subscribe to an event e by associating one of its methods to e

CISC 323, Winter 2004, Software Architecture 46

Event-Based, Implicit Invocation

❘

Components

❙

send and subscribe to events

❘

Connectors/interaction

❙

event connector

❘

Constraints

❙

Announcing components do not know

❚

who will receive their events (anonymity)

❚

in which order events will be delivered

❚

what receiving components will do in response

CISC 323, Winter 2004, Software Architecture 47

Event Subscription and Announcement

❯

Event subscription:

C2 C1

subscribe(e2,C2,m1)

❱

Event announcement: C2

Bindings: (e1, C1, m1) (e2, C2, m1)

C1

announce(e2) invoke m1

Bindings: (e1, C1, m1) (e2, C2, m1)

EC EC

CISC 323, Winter 2004, Software Architecture 48

Example

S : Set int =

❲ ❲

... if x

❳ ❳

S { S = S

❨ ❨

{x}; } ...

SetS

T : Set int =

❩ ❩

... insertT(x : int) { T = T

❨ ❨

{x}; } ...

SetT

Bindings:

EC Suppose the overall system is supposed to realize the following invariant: “After the delivery of all events, the set in T is a copy of the set in S” Question to the component integrator: “Which events and bindings should be added to make this happen?”

SLIDE 13

CISC 323, Winter 2004, Software Architecture 49

Example

S : Set int =

❬ ❬

... if x

❭ ❭

S { S = S

❪ ❪

{x}; announce(insS(x)); ...

SetS

T : Set int =

❬ ❬

... insertT(x : int) { T = T

❪ ❪

{x}; } ...

SetT

Bindings:

(insS(x), SetT, insertT(x))

EC We have invariant I:

T always is subset of S
Whenever all events are delivered, T is copy of S

Answer:

Announce insertions into S through insS(x)
Bind insertion in T to insS(x)

Another question to component integrator: “Which properties does event delivery have to have to make I true?”

CISC 323, Winter 2004, Software Architecture 50

Implicit Invocation: Advantages

❫

Announcing and receiving components do not need to know each other’s identity

❴

Less dependency, loose coupling

❴

Systems using implicit invocation are easy to modify and reuse:

❵

to add a new component C to system, C just needs to subscribe to relevant events

❵

to remove component C from system, C just needs to unsubscribe all events

❵

to replace component C by C’, remove C and add C’.

CISC 323, Winter 2004, Software Architecture 51

Adding Components

S : Set int =

❛ ❛

... if x

❜ ❜

S { S = S

❝ ❝

{x}; announce(insS(x)); ...

SetS

T : Set int =

❛ ❛

... insertT(x : int) { T = T

❝ ❝

{x}; } ...

SetT

Bindings: (insS(x), SetT, insertT(x)) (insS(x), Count, inc) (insS(x), Max, compare(x))

EC

size : int = 0 ... inc { size = size+1; } ...

Count

max : int = MinInt ... compare(x) { if (x>max) max = x; } ...

Max

keeps size of sets keeps maximal element

CISC 323, Winter 2004, Software Architecture 52

Generalized Subscriptions

❞

Instead of subscribing to events individually

subscribe(e, C, m)

components subscribe to sets of events by supplying a predicate p(e)

subscribe(p(e), C, m)

❡

p(e) characterizes the set of events the component is interested in in terms of

❢

name of e

❢

content/data of e

❢

both

❣

For example, p(e) could be

❢

e = stockPrice(x) & (x=“IBM” | x=“INTEL”)

❢

e = ins(x) & prime(x)

❢

e = login(id, pwd) & (id=“hans” | id=“franz”)

SLIDE 14

CISC 323, Winter 2004, Software Architecture 53

Adding Components

S : Set int =

❤ ❤

... if x

✐ ✐

S { S = S

❥ ❥

{x}; announce(insS(x)); ...

SetS

T : Set int =

❤ ❤

... insertT(x : int) { T = T

❥ ❥

{x}; } ...

SetT

Bindings: (insS(x), SetT, insertT(x)) (insS(x), Count, inc) (insS(x), Max, compare(x)) (insS(x)

❦

prime(x), Primes, insertPrime(x))

EC

size : int = 0 ... inc { size = size+1; } ...

Count

max : int = MinInt ... compare(x) { if (x>max) max = x; } ...

Max

primes : Set int =

❧ ❧

... insertPrime(x : int){ primes = primes

♠ ♠

{x}; } ...

Primes

CISC 323, Winter 2004, Software Architecture 54

Implicit Invocation: Disadvantages

♥

Communication between source and target is indirect ⇒ May have impact on performance ⇒ Sending large amounts of data through events can be inefficient (to overcome this, can combine implicit invocation with, e.g., shared memory)

♥

Correct behaviour of overall system depends on

♦

bindings and

♦

event delivery policy (e.g., event loss, event ordering, event delivery time)

⇒ System designer must be aware of this ⇒ May be difficult to reason about system behaviour

CISC 323, Winter 2004, Software Architecture 55

Implicit Invocation: Domain

♣

Implicit Invocation is most suited for systems that

q

require only a loose coupling of their components

q

do not have to satisfy heavy real-time constraints

q

do not exchange a lot of complex data

CISC 323, Winter 2004, Software Architecture 56

Another Example: A Program Development Environment

Compiler

EC

Debugger Profiler Editor

Events used to ensure that

editor displays appropriate code whenever debugger stops at

breakpoint

compiler recompiles system whenever a source file is modified

by editor

compiler recompiles the code with debug options enabled whenever

debugger is activated

SLIDE 15

CISC 323, Winter 2004, Software Architecture 57

Another Example: Graphical User Interface (GUI) Components

r

GUIs composed of sets of primitive components (widgets): Buttons, scroll bars, menus, dialogue boxes, etc

r

Widgets should be customizable and reusable in any context, not hand- coded for every application

r

Therefore, should be loosely coupled

r

Usually, widgets do not

s

have heavy real-time constraints

s

exchange lots of complex data Button Dialogue Box

CISC 323, Winter 2004, Software Architecture 58

GUI Components and Events

GUI components issue events when they are invoked:

t

Buttons issue “button clicked” events

t

Menus issue “menu selection” events

t

Scroll bars issue “scroll” events

t

Text fields issue “text changed” events

t

etc...

GUI Component Application Component

E

Button Web Page Navigation Component

E

Button Button

E E

Back button Reload button Forward button

CISC 323, Winter 2004, Software Architecture 59

Java Implementation of Events

✉

All events subclass

EventObject

✈

Only field is source of event (e.g., the button that raised the event)

✉

All GUI events subclass

AWTEvent

✈

Only data is id and source

✉

For example:

✇

ActionEvent for button clicks,

menu selections, etc

✇

TextEvent for entry in text field,

etc

See also http://www.javasoft.com/j2se/1.3/docs/api/index.html CISC 323, Winter 2004, Software Architecture 60

Binding Events to Code

public class MyButton extends JButton {…} public class Client { MyButton mb; public class MyListener implements ActionListener { public void actionPerformed(ActionEvent e) { if (e.getSource == mb) e.setEnabled(false); . . . } // end actionPerformed } // end class MyListener void createButton() { mb = new MyButton(); MyListener ml = new MyListener(); mb.addActionListener(ml); . . . } } // end class Client

Differences to Event-Based Style?

SLIDE 16

CISC 323, Winter 2004, Software Architecture 61

Binding Events to Code (Cont’d)

CISC 323, Winter 2004, Software Architecture 62

Implementing Event-Based Style

①

Several infrastructures available. E.g.,

②

Siena (www.cs.colorado.edu/~carzanig/siena)

③

public domain

③

APIs for Java and C++

②

Elvin (elvin.dstc.edu.au)

③

public domain

③

APIs for Java, C, C++, Perl, Palm and more

②

Gryphon (www.research.ibm.com/gryphon)

③

used for real-time sports score distribution at US Tennis Open, Ryder Cup, Australian Open, and 2000 Olympics in Sydney

CISC 323, Winter 2004, Software Architecture 63

Event-Based Style in Elvin: Simple Producer

import org.elvin.je4.*; public class DemoProducer { public static void main(String args[]) throws Exception { // create producer Producer prod = new Producer("test"); // create an event/notification Notification notif = new Notification(); // define attributes/data notif.put(“company",“IBM"); notif.put(“stockprice", 3.14); // send the event/notification prod.notify(notif); // close the connection prod.getConnection().close(); } // end main } // end class DemoProducer

CISC 323, Winter 2004, Software Architecture 64

Event-Based Style in Elvin: Simple Consumer

import org.elvin.je4.*; public class DemoConsumer implements NotificationListener { // print events when they arrive public void notificationAction(Notification event) { System.out.println(event); } public static void main(String args[]) throws Exception { // create consumer Consumer cons = new Consumer("test"); // create a subscription Subscription sub = new Subscription("company == “IBM” || company == “DELL””) && stockprice > 100"); // register a listener sub.addNotificationListener(new DemoConsumer()); // activate the subscription cons.addSubscription(sub); System.out.println("waiting for events..."); } // end main } // end class DemoConsumer

SLIDE 17

CISC 323, Winter 2004, Software Architecture 65

Architectural Styles: Roadmap

④

Client-Server (done)

④

Pipe and Filter (done)

④

Layered Systems (done)

④

Event-Based, Implicit Invocation (aka, Publish- Subscribe) (done)

④

Repositories (next)

④

Data Abstraction and Object Organization

CISC 323, Winter 2004, Software Architecture 66

Repositories

⑤

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 other

⑥

components read/write information from/to repository

⑥

repository passive

Repository C1 C2 C3

CISC 323, Winter 2004, Software Architecture 67

Example: Compiler as Pipe & Filter

Scanner Parser Semantic Analyzer Code Generator

program text executable code tokens parse tree parse tree

Implemented compiler using

Pipe & Filter architectural style ⇒ complex data structure passed through pipe several times ⇒ may be too inefficient (if, e.g., pipes are implemented using files)

store parse tree in repository instead

CISC 323, Winter 2004, Software Architecture 68

Example: Compiler as Pipe & Filter with Repository

Scanner Parser Semantic Analyzer Code Generator

program text executable code tokens control control Repository: Parse Tree

now pipes only contain less

complex data (tokens or control information)

⑧

data exchange is more efficient, if, for instance, shared memory is used to store data in repository

SLIDE 18

CISC 323, Winter 2004, Software Architecture 69

Repository: Constraints and Domain

⑨

Constraints

⑩

repository only stores information

⑩

it is not active

⑨

Domain

⑩

whenever several components need to access a large amount of fairly complex data

CISC 323, Winter 2004, Software Architecture 70

Repository: Possible Implementations

❶

Choice of implementation determines properties of access

❶

For instance,

❷

data bases: very user-friendly (e.g., built-in concurrency control) but high resource needs

❷

files: less user-friendly, but low resource needs. Components have to

❸

parse/unparse data

❸

implement queries/searches themselves

❸

implement concurrency control (e.g., mutual exclusion) themselves

❷

shared memory: somewhat user-friendly, low resource needs

❸

like files, but no parsing/unparsing necessary

CISC 323, Winter 2004, Software Architecture 71

Repository: Properties

❹

If used right, repositories can make for intuitive, readable solutions

❹

Potential problem areas:

❺

Modifiability

❻

e.g., change in data format may require every component to be changed

❺

Security

❻

may have to encrypt data in repository

❺

Availability

❻

if repository fails, whole system might fail

❺

Performance

❺

Development time

CISC 323, Winter 2004, Software Architecture 72

Repository: Performance

❼

Need to compare time needed to access repository with time needed to pass data directly from one component to next

❼

Possibility for concurrency: Requests by several components could be handled simultaneously by different threads

❼

Must make sure that repository can service requests in an appropriate amount of time, even under possibly heavy load. Must compare, e.g.,

❽

average/worst-case arrival rate of requests

❽

average/worst-case processing time of requests Repository C1 C2 C3

SLIDE 19

CISC 323, Winter 2004, Software Architecture 73

Repository: Development Time

❾

Two options:

❿

Built your own repository using, e.g.,

➀

files, shared memory

❿

Use existing repository infrastructure, e.g.,

➀

Commercial databases (e.g., DB2, MySQL)

➀

Jini/JavaSpaces

❾

Need to

❿

know required properties of repository access

❿

balance savings in development time vs need to learn infrastructures

Repository C1 C2 C3

CISC 323, Winter 2004, Software Architecture 74

Blackboard Architecture Style

➁

Variant of repository

➁

Repository is active

➂

Can activate components in response to changes in blackboard contents

➁

Typical application:

➂

Use blackboard to mediate cooperative activity amongst components

➂

Tasks where desired outcome is imprecisely defined or error prone

Update/request information from repository Activate components as new information becomes available Repository C1 C2 C3

HTTP Server

(e.g. Apache)

HTTP Client

(e.g., Netscape, Internet Explorer)

Order System Inventory Catalogue

Requests for book info, delivery times, orders, etc. HTML document Requests for book info Requests for delivery time Order placement Request availability

Recall example of online book ordering system...

CISC 323, Winter 2004, Software Architecture 76

Example: Inventory System Using Blackboard Architecture

➃

Inventory blackboard used to coordinate filling orders

➃

Order system initiates

rders

➃

Receiver records new stock as it arrives

➃

Shipper sends order to be packaged

➃

All communication via inventory Order System Inventory

Request availability

Receiver Shipper

Record new stock Record stock shipped Inform

rder filled

Initiate shipping Order stock

SLIDE 20

CISC 323, Winter 2004, Software Architecture 77

Architectural Styles: Roadmap

➄

Client-Server (done)

➄

Pipe and Filter (done)

➄

Layered Systems (done)

➄

Event-Based, Implicit Invocation (aka, Publish- Subscribe) (done)

➄

Repositories (done)

➄

Data Abstraction and Object Organization (next)

CISC 323, Winter 2004, Software Architecture 78

Data Abstraction and Object-Oriented Organization

➅

An architectural style we’re already familiar with

➅

Components: Objects

➅

Interactions: Method invocations

➅

Constraints:

1. Objects are responsible for maintaining the integrity
f their representation/implementation
2. Objects hide representation details

CISC 323, Winter 2004, Software Architecture 79

Example

public class Set { private Vector v = new Vector(); // representation/class invariant: size is // equal to number of different objects in v private int size = 0; public int getSize() {return size;} public void insert(Object o) { if (!v.contains(o)){ v.addElement(o); size = size + 1; } } . . . } // class Set

Constraint 1): code must maintain class invariant Constraint 2): code must hide representation details

CISC 323, Winter 2004, Software Architecture 80

Advantages

➆

Modifiability: details of representation/implementation can be changed without having to change client code

➆

Modularity: system can be broken up along logical, conceptual lines, i.e., into data and behaviour that belong together, because they offer a particular service

SLIDE 21

CISC 323, Winter 2004, Software Architecture 81

Disadvantages

➇

Interactions typically require knowledge of the components involved (in contrast to, e.g., Pipe & Filter, Event-based/Implicit Invocation)

➈

this can lead to tightly-coupled systems and decreased modifiability

CISC 323, Winter 2004, Software Architecture 82

Software Architecture: Case Studies

➉

Two case studies in courseware:

1. Instrumentation Software for Tektronics

Oscilloscopes

➊

not on slides

2. Mobile Robotics

➊

Control Loop (have not seen this style yet)

➊

Layers

➊

Implicit Invocation

➊

Blackboard

CISC 323, Winter 2004, Software Architecture 83

Mobile Robotics

➋

Mobile robots already used for

➌

scientific purposes, e.g.,

➍

space and underwater exploration

➌

environmental purposes, e.g.,

➍

hazardous waste disposal (e.g., Tschernobyl)

➌

industrial purposes, e.g.,

➍

pipe cleaning

➌

service, e.g.,

➍

food delivery in hospitals

➋

In future, perhaps also for domestic purposes like vacuum cleaning!?

CISC 323, Winter 2004, Software Architecture 84

Mobile Robotics: Requirements

➎

Software architecture for robot must

➏

R1 (Movement): support deliberate and reactive behaviour

➐

e.g., collect rocks and avoid obstacles

➏

R2 (Uncertainty): allow for incomplete, unreliable, inconsistent information

➏

R3 (Safety): protect the robot through

➐

e.g., fault tolerance, or safety or real-time guarantees

➏

R4 (Modifiability): be easily modifiable

➎

Compare 4 architectures with respect to these requirements

SLIDE 22

CISC 323, Winter 2004, Software Architecture 85

Mobile Robotics: Control Loop

Controller Actuators Sensors Environment

Action Feedback Robot

CISC 323, Winter 2004, Software Architecture 86

Mobile Robotics: Control Loop

➑

R1 (Movement):

➒

natural, simple architecture to control simple movements

➒

but no guidance on how realize complex tasks

➑

R2 (Uncertainty):

➒

deals with uncertainty through trial and error

➒

but no explicit support for more sophisticated approaches

➑

R3 (Safety):

➒

simplicity allows achieving fault-tolerance by replication

➑

R4 (Modifiability):

➒

modifications to top-level components easy

➒

modifications to smaller, low-level components potentially much harder

Controller Actuators Sensors Environment Action Feedback Robot

CISC 323, Winter 2004, Software Architecture 87

Mobile Robotics: Layers

Environment Supervisor Global planning Control Navigation Real-world modeling Sensor integration Sensor interpretation

CISC 323, Winter 2004, Software Architecture 88

Mobile Robotics: Layers

➓

R1 (Movement):

➔

each layer has different view

➔

better architectural support for motion planning

➓

R2 (Uncertainty):

➔

higher layers have more abstract, global view

➔

deal with uncertainty through delegation

➓

R3 (Safety):

➔

more comprehensive checks through safety checks on different levels

➔

real-time constraints difficult to meet with strict layering

➓

R4 (Modifiability):

➔

depends on complexity of interaction between adjacent layers

Environment Supervisor Global planning Control Navigation Real-world modeling Sensor integration Sensor interpretation

SLIDE 23

CISC 323, Winter 2004, Software Architecture 89

Mobile Robotics: Implicit Invocation

EC Task Task Task Task Task Gather rock Go to position Grab rock Lift rock Move left Move forward Task Tree

CISC 323, Winter 2004, Software Architecture 90

Mobile Robotics: Implicit Invocation

→

R1 (Movement):

➣

can break planning easily into as many components as necessary

→

R2 (Uncertainty):

➣

can easily add components that deal with uncertainty

→

R3 (Safety):

➣

easy to achieve fault-tolerance through redundancy

➣

real time requirements can be accommodated (to an extend)

→

R4 (Modifiability):

➣

easy to add, remove, replace components

EC Task Task Task Task Task

CISC 323, Winter 2004, Software Architecture 91