1 Architectural Design Overall structure design of a software system Multiple architecture design modules (styles) may need for architectural design.

1

Architectural Design

Overall structure design of a software system

Multiple architecture design modules (styles) may need for architectural design.

2

Architecture Model Types

General architectural models (styles)

Domain-specific architecture models Generic model – Compiler Model Reference model – OSI

3

Architectural Design Phase

Architectural Design – Macro Design

Detailed Design – Micro Design Architectural Design – Detailed

Design

4

Architectural Design Process

System structuring and partitioning

Decomposition of software system into sub-systems and communications between sub-systems

Sub-system is an independent system from other sub-systems.

5

Architectural Design Process

Controlling Models Control relationships between

different sub-systems Data flow controlling Control flow controlling

6

Architectural Design Process

Modular Decomposition Decomposition of sub-system into

components Component (module in pop) provides

services to other component. Reuse component

7

Architectural Design Process

8

Architectural Styles

Pattern, common form design, organizational principles, and structure for certain classes of software

Trade-off in selecting one style over an other

9

Architectural Attributes Performance

Localize operations to minimize sub-system communication

Security Use a layered architecture with critical assets in inner

layers Safety

Isolate safety-critical components Availability

Include redundant components in the architecture Maintainability

Use fine-grain, self-contained components

10

Architectural Design CASE

Static structural model Use CASE, UML

Dynamic process model Sequence diagram DFD

11

Architecture Style Component (vocabulary)

Service provider or requester Client, server, filer, layer, database

Connectors Interaction among components Procedure call, event broadcast, pipe

Constraints Combination of components and connectors

12

Common Architectural Styles Pipes and filters (Data flow) vs. batch sequential system Layered Repository (Data Centered) Interpreter (Virtual Machine) Event-based (Independent Component) Object-oriented Component Component-based Process control Domain-specific Implicit invocation (asynchronous) (message queue) MVC (PAC)

13

Software Architecture Design Methods

Structured-oriented Design Object-oriented Design Component-oriented Design Service-oriented Design Aspect-oriented Design

14

Software Architecture Software architecture is the structure of a

software system consisting of software components, connection between components, attributes or properties

A software component is a software entity with a well defined interface. It can be an object, package, DB, API, or a subsystem

One system requirement may result in multiple architectures by different architects

15

Software Architecture

Influential factors to architecture Technical - Platform Social - Expertise Business Stakeholders

Management - Schedule, budget, resource Market - Feature, Time in market Maintenance - Modifiability Customer - Timing End-user - Performance

Contd.

16

Architectural Attributes(Quality Attributes)

Run-time attributes (observable at run-time)

Availability - Dual server, risk of shut down, failures of hardware, software, network.

Security - Firewall, authentication, or algorithm, risk of unsecured

Performance - Turnaround time, throughput, risk of poor performance accuracy, speed, space

Usability & Functionality - Completeness, correctness, compatibility

17

Architectural Attributes Implementation attributes (Not observable

at run-time) Maintenance - Evolution, change, risk of

unchangeable expandability Testability - Quality assurance, risk of bugs,

faults Portability - OS independent, risk of tight

dependency Scalability - Adaptive to volume, risk of neck

bottle Interoperability - Universal accessibility, risk of

tight dependency of infrastructure

Contd.

18

Architectural Attributes

Business Qualities Time in market Cost Complexity Lifetime

Contd.

19

Architectural Attributes Trade off between attributes Choose right architecture to reduce the

risks Impact of architecture on quality attributes Trade off between space vs. time Trade off between dependability and

performance Trade off between liability and

performance Required quality attributes are identified in

requirement process.

Contd.

20

Architecture Design Processing

Analyze requirement - domain Create business–use - case Select architecture style (component,

link ) Communicating architecture to

stakeholders (prototypes) Evaluate architecture Implementation architecture - detail

design

21

Architecture Concept

Reference Model

Architecture Style

Reference Architecture

Compiler a

pipe & filer b

Repository c

a-b

or

a-c

22

Architecture Style

Virtual machines Independent component Data Flow Data centered Call & Ret Heterogeneous MVC

23

Architecture Views Use-case view - End User’s view of functionality Logical view - System analyst/designer’s view of

concept Implementation view - Programmer's view of

software development Process view - System integration view of

performance sync, async, thread, concurrent, real-time

Deployment view - Software engineer's view of installation, deployment, delivery, documentation

24

Architecture Views

Data flow view Control flow view Invocation view

Physical view-distributed, parallel, processors

Data

No

Yes

Contd.

25

Subsystem Configured, delivered, developed, deployed, replaceable Identification by object operation, object collaboration User interface, actor, substitution, distribution Independent evolution Interface encapsulates details Loose coupling Interface of a subsystem has its responsibilities Interface specifies its operation Interface has an ID name Interface supports plug in and play

26

SubsystemContd.

Student

Course Catalog

Faculty

interface

interface

interface

27

Architecture Styles

Set of rules, constraints, or patterns of how to structure a system into a set of components and connectors

What is about How to control logic flow and data

transfer Where to apply

28

Architecture Styles

Pipes & Filters Event-based Data-centered Interpreter MVC Message dispatcher

Contd.

29

Partition Guideline

Coupling and cohesion User organization Competency and/or skill areas System distribution Security Variability

30

Layered Architecture Software system consists of more general

abstract services in the bottom rising up to more specific application on top.

Each layer depends on its adjacent lower layer. Each lower layer provides service to its upper layer.

Each layer has two interfaces. Upper interface provides services. Lower interface requires services.

31

Layered Architecture

Breach may cause deadlock. Callback technique can be used to avoid it.

Contd.

breach

bridging

breach

32

Layered Architecture

J2EE application server, SOAP application server

Contd.

EJB Container

Transaction J2EE Server

Web Container

Web App.EJB App.

J2EE

HTTP

TCP

SOAP

IP

Web Service

OSI

Application Layer

Presentation Layer

Session Layer

Transportation Layer

Network Layer

Data Link Layer

Psychical Layer

33

Layered Architecture Design Guideline Each layer has its own responsibilities Design Interfaces (providing service) Compatible of interfaces Partition each layer into components and

specify communication upper layer don't see the implementation of lower layer

Support reuse, modifiable maintenance, independence

Plug-replace layer-encapsulation Cost, difficult to get divisions

34

Layered Architecture Design Guideline

Trade off modifiability & service vs. performance

3-5 layers up to 7 layers

XML

HTTP

SOAP

TCP

Web Service

XML

HTTP

SOAP

TCP

IP IP

35

Advantages:

Support designs based on increasing levels of abstraction

Support enhancement: changes to the function of one layer affect at most two other layers

Support reuse: allow different implementations of the same layer

36

Disadvantages:

Not all systems are easily structured in a layered fashion.

Even a system can logically be structured in layers, considerations of performance may require closer coupling.

It may be quite difficult to find the right levels of abstraction.

37

Layered Application Design Structure application in two layers

Interaction Layer and Processing Layer

Interaction layer Interface to clients Receive requests and transform it Forward request to processing layer for processing Respond to clients

Client

Interaction Layer

Processing Layer

38

Layered Application Design

Processing layer business logic process Access database Integrate with EIS

39

Why Layered?

Clearly divide responsibilities De-couple business logic from

presentation Change in business logic layer does

not affect the presentation layer and vice-versa

40

Model-Encapsulates application state-Responds to state queries-Exposes application functionally-Notifies views of changes

Controller-Defines Application behavior-Maps user action to model updates-Select view for response-One for each functionality

View-Renders the model -Requests updates from models -Sends user gestures to controller-Allow controller to select view

User Gestures

View Selection

State Query

Change Notification

State Change

Method Invocations

Events

MVC Pattern

41

Three Logical Layers in a Web Application: Model Model (Business process layer)

Models the data and behavior behind the business process

Responsible for actually doing: Performing DB queries Calculating the business process Processing orders

Encapsulate of data and behavior which are independent of presentation

42

Three Logical Layers in a Web Application: View

View (Presentation layer) Display information according to

client types Display result of business logic

(Model) Not concerned with how the

information was obtained, or from where

43

Three Logical Layers in a Web Application: Controller Controller (Control layer)

Serves as the logical connection between the user's interaction and the business services on the back

Responsible for making decisions among multiple presentations e.g.

User's language, locale or access level dictates a different presentation.

A request enters the application through the control layer, it will decide how the request should be handled and what information should be returned

44

Web Applications It is often advantageous to treat each layer

as an independent portion of your application

Do not confuse logical separation of responsibilities with actual separation of

components Some or of the layers can be combined into single components to reduce application complexity

45

Enterprise Information System()EIS

BROWSER

Java Bean

JSP Pages

Servlet Container

Request

4

1

Response

2

3

46

Page-centric Architecture Composed of a series of interrelated JSP pages

JSP pages handle all aspects of the application -

presentation, control, and business process Business process logic and control decisions

are hard coded inside JSP pages in the form of JavaBeans, scriptlets, expression

Next page selection is determined by A user clicking on a hyper link, e.g. <A

HERF="find.jsp> Through the action of submitting a form, e.g. <FORM

ACTION="search.jsp">

47

Page-centric Architecture

Database

Page-Centric Catalog Application

Menu.jsp

Catalog.jsp

Checkout.jsp

48

Pipe-and-Filter Architecture

P&F architecture consist of producer/consumer subsystems each subsystem may produce, consume, or consume/produce data and connectors (pipes) to forward the data from one filter to another involving transformation on streams of data.

49

Diagram

Filter Filter Filter

Filter

Pipe

Pipe

Pipe

Pipe

Pipe

50

Example

Unix command who | sort | Lp sort is a filter using a pipe to

connect stdout of who to input interface of another pipe to connect its stdout to stdin of input of next command lp.

51

Diagram

Source Text

Lexical Analysis

Syntax Analysis

Semantic Analysis

Code Generation

Target Code

x=x+1;

Token1Token2..

X=x+1;

=

x

x

+

1

Type checked parse tree

Parse tree

52

Domain of F & P

Problem can be divided into a sequence of processing steps over data stream.

The data format transformation in each filter is well defined.

53

Advantages: Let the designer to understand the overall

system as a simple composition of the behaviors of the individual filter.

They support reuse. Systems are easy to maintain and

enhance: by adding or modifying filters. Permit certain kinds of specialized analysis:

throughput and deadlock. Support concurrent execution.

54

Disadvantages: Leading to a batch organization of processing They may be hampered by having to

maintain correspondence between two separate but related stream.

They may force a lowest common denominator on data transmission, resulting in added work for each filter. Can lead both to loss of performance and to increase complexity in writing the filters themselves.

55

Event-Based Architecture

Event targets can register or unregistered with an event source register. Event source has no direct reference to target directly. The broadcasting mode is asynchronous mode.

Event Source Event Sink1

Event Sink2

Subscribe(register)

Publish(broadcast)

56

Event-Based Architecture

Domain: 1) Source component will be reused. 2) Broadcasting mode 3) Asynchronous mode 4) Event is not predicted.

57

Advantages:

Provide strong support for reuse: Any component can be introduced into a system simply by registering it for the events of the system.

Easing system evaluation: Components can be replaced by other components without affecting the interfaces of other components in the system.

58

Disadvantages:

components relinquish control over the computation performed by the system

exchange of data

reasoning about correctness can be problematic.

59

Diagram

buttom

ActionListener

actionPerformed()

actionPerformed()

ActionListener

ActionListener

60

Implementationimport java.applet.*;import java.awt.*;import java.awt.event.*;

public class clicker extends Applet implements ActionListener{TextField text1;Button button1;

public void init(){ text1=new TextField(20);

add(text1);button1=new Button(“Click Me”)add(button1);button1.addActionListener(this);

}

public void actionPerformed(ActionEvent event){String msg=new String(“Welcome to Java”);if(event.getSource()==button1){ text1.setText(msg);

} }}

61

Java Event ImplementationInterface

Runnable

addEventListener()

removeEventListener()eventTrigger()

Event Source

Vector V

0 n-1

…

(thread)

Event Sink2

handleEvent2(EventObject)

Event Sink1

handleEvent1(EventObject)

EventListener

Interface

Implements

scan

1

62

Java Event Implementation

All events subclass EventObject class All GUI event subclass of AWTEvent EventListener

public interface MyListener extends EventListener

{void handleEvent(EventObject e);}

63

EventObject

public class MyEventObject extends EventObject

{ long t1; public MyEventObject(Object o){

super(o); t1=System.currentTime(); }

public long getTime(){ return t1;}}

64

Event Sink:

public class Sink implements MyListener{

...........public void handleEvent(EventObject e){System.out.println("Time is"+ e.getTime());

}........}

65

Event Sourcepublic class Source implements Runnable{

Vector v=new Vector();Thread thread;

public Source(){Thread=new Thread(this); thread.start(); }.....public void run(){ while(true) {triggerEvent(); try{thread.sleep(1000); } catch (Exception e){} }}

66

Event Sourcepublic synchronized void addMyListener (MyListener l){ v.addElement (l);}

void triggerEvent(){ MyEventObject meo=new MyEventObject (this);

for(int i=0; i<v.length;i++) MyListener wl=v.elementAt(i);

wl.handleEvent(meo);}

67

Registration strap

main()

{

Source s1=new Source();

Sink t1=new Sink();

s1.addMyListener(t1);

.

.

}

68

Data-Centered Architecture Style

Repository (passive) centralized data storage (database or data structure) for multiple components to share to R/W

Blackboard (active) Repository may activate components

when data in blackboard is changed. Coordinate components

69

Repository

Repository vs. Filter & Pipe Example 1

lexical syntactic

token

semantic

flowcontrol

flowcontrol code

generation

parse tree

70

Repository Example 2:

Web service WSDL Repository Example 3:

CORBA Interface Repository (IR) Advantage:

Less overhead vs. F&P Actor does not depend on each other and it

is easy to add new actor. Actor concurrent access consistent data

Contd.

71

Repository

Disadvantage: More overhead in distributed

application Need to be scalable Security issue Availability issue Change Repository, evolution is difficult Potential slow problem

Contd.

72

Repository

Exampleheater

Air Conditioner

temperature

start heat

start cooling

panel

set

reset

CASE TOOL

Design Analyzer

Design Editor

Program Editor

Code Generation

Report Generation

Contd.

73

Repository

All shared data is held in a central DB that can be accessed by all components.

Each component keep its own DB and exchange data via message.

Contd.

74

Interpreter Style An interpreter is a virtual machine

on the top of physical machine. The interpretation engine (virtual machine (VM)) interprets the pseudo code.

The VM kayos tracks of current states of the code execution.

The pseudo code includes program itself and program data, state.

75

Diagram

Determine next code

execFetch next code

76

Diagram

pseudo program

interpreter engine

interpreter state

program state

data input

output

77

Process Control Style

Control system is to maintain specified properties of the outputs of process at a given reference value.

78

Process Control Style Process variable: Properties of the process that

can be measured; several specific kinds are often distinguished.

Controlled variable: Process variable whose value the system is intended to control.

Input variable: Process variable that measures an input to the process.

Manipulated variable: Process variable whose value can be changed by the controller.

Set point: The desired value for a controlled variable.

Open-loop system: System in which information about process variables is not used to adjust the system.

79

Process Control Style Closed-loop system: System in which

information about process variables is used to manipulate a process variable to compensate.

Feedback control system: The controlled variable is measured, and the result is used to manipulate one or more of the process variables.

Feed forward control system: Some of the process variables are measured, and anticipated disturbances are compensated for without waiting for changes in the controlled variable to be visible.

80

Feedback control close loop control model

Thermostat

Request service Turned on or off

Temperature change

Temperature sensor

Heating or Cooling Device

81

Feedback control close loop control model

process

Manipulated variables

Controller

GoalControlled variable

Input variable

82

Feed Forward Control

process

Manipulated variables

Goal

Controlled variable

Input variable

Controller