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
Contd.

• 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

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
Contd.

• 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

18
Architectural Attributes
Contd.

• Business Qualities
• Time in market
• Cost
• Complexity
• Lifetime

19
Architectural Attributes
Contd.

• 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.

20
Architecture Design Processing

• Analyze requirement - domain
• Create businessuse - case
• Select architecture style (component, link )
• Communicating architecture to stakeholders
  (prototypes)
• Evaluate architecture
• Implementation architecture - detail design

21
Architecture Concept
22
Architecture Style

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

23
Architecture Views

• Use-case view - End Users view of functionality
• Logical view - System analyst/designers 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
Contd.

• Data flow view
• Control flow view
• Invocation view
• Physical view-distributed, parallel, processors

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
Subsystem
Contd.
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
Contd.

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

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
Contd.

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

32
Layered Architecture
Contd.

• J2EE application server, SOAP application server

Web Service
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

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
(No Transcript)
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
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. ltA
  HERF"find.jspgt
• Through the action of submitting a form, e.g.
  ltFORM
• ACTION"search.jsp"gt

47
Page-centric Architecture
Menu.jsp
Catalog.jsp
Checkout.jsp



Database
Page-Centric Catalog Application
48
Pipe-and-Filter Architecture

• PF 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
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
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.

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
ActionListener
ActionListener
ActionListener
buttom
actionPerformed()
actionPerformed()
60
Implementation

• import java.applet.
• import java.awt.
• import java.awt.event.
• public class clicker extends Applet implements
  ActionListener
• TextField text1
• Button button1
• public void init()
• text1new TextField(20)
• add(text1)
• button1new Button(Click Me)
• add(button1)
• button1.addActionListener(this)
• public void actionPerformed(ActionEvent event)
• String msgnew String(Welcome to Java)
• if(event.getSource()button1)

61
Java Event Implementation
Interface
Interface
Runnable
(thread)
EventListener
Implements
Event Source
addEventListener()
Event Sink1
removeEventListener()
handleEvent1 (EventObject)
eventTrigger()
Vector V
0
n-1
1
Event Sink2

handleEvent2 (EventObject)
scan
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)
• t1System.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 Source

• public class Source implements Runnable
• Vector vnew Vector()
• Thread thread
• public Source()Threadnew Thread(this)
• thread.start()
• .....
• public void run()
• while(true) triggerEvent()
• 
  trythread.sleep(1000)
• catch
  (Exception e)

66
Event Source

• public synchronized void addMyListener
  (MyListener l)
• v.addElement (l)
• void triggerEvent()
• MyEventObject meonew MyEventObject (this)
• for(int i0 iltv.lengthi)
• MyListener wlv.elementAt(i)
• wl.handleEvent(meo)

67
Registration strap

• main()
• Source s1new Source()
• Sink t1new 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

70
Repository
Contd.

• Example 2
• Web service WSDL Repository
• Example 3
• CORBA Interface Repository (IR)
• Advantage
• Less overhead vs. FP
• Actor does not depend on each other and it is
  easy to add new actor.
• Actor concurrent access consistent data

71
Repository
Contd.

• Disadvantage
• More overhead in distributed application
• Need to be scalable
• Security issue
• Availability issue
• Change Repository, evolution is difficult
• Potential slow problem

72
Repository
Contd.

• Example

73
Repository
Contd.

• 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.

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
76
Diagram
data input
program state
pseudo program
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
81
Feedback control close loop control model
82
Feed Forward Control
Input variable
process
Goal
Manipulated variables
Controlled variable
Controller