1 Architectural Design Overall structure design of a software system Multiple architecture design...
-
Upload
howard-clarke -
Category
Documents
-
view
216 -
download
0
Transcript of 1 Architectural Design Overall structure design of a software system Multiple architecture 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