8/6/2019 Unit 4 Part2

http://slidepdf.com/reader/full/unit-4-part2 1/7

Processing elements and connecting elements in Multi phase 

Architectural style: 

1.  The Multi‐phase architectural style consists of  processing elements and data elements 

that  are  exchanged  between  processing  elements.  For  example,  the multi‐phase  style  for  a 

compiler includes: 

•  Processing elements: lexer, parser, semantor, optimizer, code generator 

•  Data  elements:  characters,  tokens,  phrases,  correlated  phrases,  annotated 

phrases, object code. 

2.  If  the multi‐phase architectural style is organized sequentially, it also uses the following 

connecting elements: 

•  Connecting elements: procedure calls and parameters. 

3.  The form of  an architectural style is expressed by weighted properties and relationships 

among its architectural elements. 

Architectural styles & Patterns 

4.  Architectural  styles  only  describe  the  overall  structural  frame works  for  applications. 

Patterns  for  software  architecture,  however,  exist  in  various  ranges  of   scale,  beginning with 

patterns for defining the basic structure of  an application and ending with patterns that describe 

how to implement a particular design issue in a given programming language. 

5.  Architectural  styles  are  independent  of   each  other,  but  a  pattern  depends  on  the 

smaller patterns it contains, on the patterns with which it interacts, and on the larger patterns in 

which it is contained. 

6.  Patterns are more problem‐oriented than architectural styles. 

7.  Architectural styles express design techniques form a viewpoint that  is  independent of  

an actual design situation. 

8/6/2019 Unit 4 Part2

http://slidepdf.com/reader/full/unit-4-part2 2/7

8.  A pattern expresses a very specific recurring design problem and presents a solution to 

it, all from the viewpoint of  the context in which the problem arises. 

Construction of  software is based on several fundamental principles: 

Enabling techniques: 

•  Abstraction 

•  Encapsulation 

•  Information Hiding 

•  Modularization 

•  Separation of  concerns 

• Coupling

 

and 

Cohesion 

•  Sufficiency, Completeness and Primitiveness 

•  Separation of  Policy and Implementation 

•  Separation of  Interface and Implementation 

•  Single point of  Reference 

•  Divide‐and‐Conquer 

•  Abstraction 

Abstraction is "the process of  forgetting information so that things that are different can be 

treated as if  they were the same." [Lis01] In the context of  software design, two key abstraction 

mechanisms are parameterization and specification. Abstraction by specification leads to three 

major kinds of  abstraction: procedural abstraction, data abstraction, and control (iteration) 

abstraction. 

•  Coupling and cohesion 

Coupling is defined as the strength of  the relationships between modules, whereas cohesion is 

defined by how the elements making up a module are related. 

•  Decomposition and modularization 

8/6/2019 Unit 4 Part2

http://slidepdf.com/reader/full/unit-4-part2 3/7

Decomposing and modularizing large software into a number of  smaller independent ones, 

usually with the goal of  placing different functionalities or responsibilities in different 

components. 

•  Encapsulation/information hiding 

Encapsulation/information hiding means grouping and packaging the elements and internal 

details of  an abstraction and making those details inaccessible. 

•  Separation of  interface and implementation 

Separating interface and implementation involves defining a component by specifying a public 

interface, known to the clients, separate from the details of  how the component is realized. 

•  Sufficiency, completeness and primitiveness 

Achieving sufficiency, completeness, and primitiveness means ensuring that a software 

component captures all the important characteristics of  an abstraction, and nothing more. 

Some variants of  Data flow systems and Repositories 

Variants of  Dataflow systems: 

•  The dataflow architecture that repeatedly occurs in the evolution of  shared information 

systems  is  the batch  sequential pattern. However,  the most  familiar example of   this genre  is 

probably the Unix pipe‐and‐filter system. 

•  The similarity of  these architectures is apparent in the diagrams used for systems of  the 

respective  classes,  as  indicated  in  figure.  Both  decompose  a  task  into  a  fixed  sequence  of  

computations. 

•  They  interact only  through  the data passed  from one  to another and  share no other 

information. 

•  They assume  that  the  components  read and write  the data as a whole  –  that  is,  the 

input or output contains one complete instance of  the result in some standard order. There are 

differences, though. 

8/6/2019 Unit 4 Part2

http://slidepdf.com/reader/full/unit-4-part2 4/7

Batch sequential systems have the following characteristics: 

o  Very coarse‐grained 

o  Unable to provide feedback in real time 

o  Unable to exploit concurrency 

o  Unlikely to proceed at an interactive pace 

On the other hand, pipe‐and‐filter systems are characterized as follows: 

•  Fine‐grained, beginning to compute as soon as they consume a few input tokens 

•  Able to start producing output right away (processing is localized in the input stream) 

•  Able to provide feedback (though most shells can’t express it) 

•  Often interactive 

Variants of  Repositories: 

•  Repositories in general are characterized by a central shared data store couple tightly to 

a number of  independent computations, each with its own expertise. 

•  The independent computations interact only through the shared data, and they do not 

retain any significant amount of  private state. 

•  The  variations  differ  chiefly  in  the  apparatus  that  controls  the  order  in  which  the 

computations are  invoked,  in the apparatus that controls the order in which the computations 

are invoked, in the access mechanism that allow the computations access to the data, and in the 

granularity of  the operations. 

• In

 

a 

database 

system 

the 

control 

is 

driven 

by 

the 

types 

of  

transactions 

in 

the 

input 

stream, the access mechanism is usually supported by a specialized programming language, and 

the granularity is that of  a database transaction. 

8/6/2019 Unit 4 Part2

http://slidepdf.com/reader/full/unit-4-part2 5/7

• acces

repre

 

• may 

by a

 

The follo

s  mechanis

sentation, or

The follo

be determi

 event mec

ing figure sh

  may  be  fu

 direct acces

ing figure 

ed by the 

hanism also 

ows a progr

ll  conversio

, and the gra

hows a rep

irect reque

shared by t

mming lang

  of   the  sha

nularity is th

ository that 

sts of  users,

he tools. 

age compile

red  data  str

at of  a single 

supports in

 or it may i

r. Here contr

ucture  into 

pass of  a co

dependent 

some case

ol is fixed, th

n  in‐memo

piler 

ools. Contr

s be handle

e 

y 

l 

d 

8/6/2019 Unit 4 Part2

http://slidepdf.com/reader/full/unit-4-part2 6/7

 

• set. 

• com

archi

• cont

• repr

• the 

expe

quite

 

A variety 

One  pro

leteness‐to

tectures fre

Here  the 

ibute to sol

The blac

sentations 

Control  i

lackboard. 

rts watchin

 fine, at the 

of  access m

inent  rep

  extend  t

quently use

independe

ing the pro

 board  is h

ertinent to

 completel

The abstrac

  each othe

level of  int

ethods are 

sitory  has 

e  compari

 for signal‐

nt  computa

blem. 

ighly  struct

 the applica

 opportuni

t model  for

r  solve a p

rpreting a s

available, a

not  appea

son  of   re

processing 

tions  are  v

red  repres

tion. 

stic, driven 

access  is d

roblem at a

ignal segme

d the gran

ed  here;  i

ositories. 

pplications 

arious  kno

entation es

by  the curr

irect visibili

  real black

nt as a pho

larity is tha

  is  mentio

his  is  th

in artificial i

ledge  sour

ecially desi

ent state of 

ty, as with 

oard.  The 

eme. 

t of  the too

ed  now  f 

  blackboar

ntelligence.

ces  that  ca

gned  for  th

  the data o

many huma

granularity 

l‐

r 

d 

n 

e 

n 

n 

is 

8/6/2019 Unit 4 Part2

http://slidepdf.com/reader/full/unit-4-part2 7/7

Basic Interactive Behavior for user‐interactive architecture: 

Basic  interface  class  identifies  the  basic  kind  of   interaction  supported  by  the  user‐interface 

system.( A general‐purpose system might support more than one of  these classes.). The design 

space uses a classification proposed by Shneiderman [Shn86]: 

•  Menu selection: Based on repeated selection from groups of  alternatives; at each step 

the alternatives are (or can be) displayed. •  Form  filling: Based on entry (usually text entry) of  values for a given set of  variables. •  Command   language: Based  on an artificial, symbolic  language; often allows extension through  procedure definitions that  resemble a  programming language. •  Natural  language: Based  on (a subset  of) a human language such as English. Resolution of  ambiguous input  is a key   problem. •  Direct   manipulation:  Based   on  direct   graphical   representation  and   incremental  manipulation of  the  program’s data. It  turns out  that  menu selection and   form  filling can be supported  by  similar  system structures, but  each of  the other  classes has unique requirements.