Architectural Design n n Overall structure design of

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

Architecture Model Types n n General architectural models (styles) Domain-specific architecture models n n Generic model – Compiler Model Reference model – OSI 2

Architectural Design Phase n n n Architectural Design – Macro Design Detailed Design – Micro Design Architectural Design – Detailed Design 3

Architectural Design Process n n n 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. 4

Architectural Design Process n Controlling Models n n n Control relationships between different sub -systems Data flow controlling Control flow controlling 5

Architectural Design Process n n Modular Decomposition of sub-system into components n n Component (module in pop) provides services to other component. Reuse component 6

Architectural Design Process 7

Architectural Styles n n Pattern, common form design, organizational principles, and structure for certain classes of software Trade-off in selecting one style over an other 8

Architectural Attributes n Performance n n Security n n Isolate safety-critical components Availability n n Use a layered architecture with critical assets in inner layers Safety n n Localize operations to minimize sub-system communication Include redundant components in the architecture Maintainability n Use fine-grain, self-contained components 9

Architectural Design CASE n Static structural model n n Use CASE, UML Dynamic process model n n Sequence diagram DFD 10

Architecture Style n Component (vocabulary) n n n Connectors n n n Service provider or requester Client, server, filer, layer, database Interaction among components Procedure call, event broadcast, pipe Constraints n Combination of components and connectors 11

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

Software Architecture Design Methods n n n Structured-oriented Design Object-oriented Design Component-oriented Design Service-oriented Design Aspect-oriented Design 13

Software Architecture n n n 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 14

Contd. Software Architecture Influential factors to architecture n n Technical - Platform Social - Expertise Business Stakeholders n n n Management - Schedule, budget, resource Market - Feature, Time in market Maintenance - Modifiability Customer - Timing End-user - Performance 15

Architectural Attributes (Quality Attributes) n Run-time attributes (observable at run-time) n n 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 16

Contd. Architectural Attributes n Implementation attributes (Not observable at run-time) n n n 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 17

Contd. Architectural Attributes n Business Qualities n n Time in market Cost Complexity Lifetime 18

Architectural Attributes n n n n 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. 19

Architecture Design Processing n n n Analyze requirement - domain Create business–use - case Select architecture style (component, link ) Communicating architecture to stakeholders (prototypes) Evaluate architecture Implementation architecture - detail design 20

Architecture Concept Compiler a Reference Model Reference Architecture pipe & filer b Architecture Style a-b or a-c Repository c 21

Architecture Style n n n n Virtual machines Independent component Data Flow Data centered Call & Ret Heterogeneous MVC 22

Architecture Views n n n 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, realtime Deployment view - Software engineer's view of installation, deployment, delivery, documentation 23

Contd. Architecture Views n n n Data flow view Control flow view Invocation view Data Yes No n Physical view-distributed, parallel, processors 24

Subsystem n n n n n 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 25

Contd. Subsystem interface Student interface Course Catalog interface Faculty 26

Architecture Styles n n 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 27

Contd. Architecture Styles n n n Pipes & Filters Event-based Data-centered Interpreter MVC Message dispatcher 28

Partition Guideline n n n Coupling and cohesion User organization Competency and/or skill areas System distribution Security Variability 29

Layered Architecture n n n 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. 30

Contd. Layered Architecture breach bridging breach n Breach may cause deadlock. Callback technique can be used to avoid it. 31

Contd. Layered Architecture J 2 EE application server, SOAP application server n J 2 EE EJB App. Web App. EJB Container Web Container Transaction J 2 EE Server Web Service SOAP HTTP TCP IP OSI Application Layer Presentation Layer Session Layer Transportation Layer Network Layer Data Link Layer Psychical Layer 32

Layered Architecture Design Guideline n n n n 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 33

Layered Architecture Design Guideline SOAP n n Web Service SOAP XML HTTP TCP IP IP Trade off modifiability & service vs. performance 3 -5 layers up to 7 layers 34

Advantages: n n n 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 35

Disadvantages: n n n 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. 36

Layered Application Design n Structure application in two layers n n n Interaction Layer and Processing Layer Client Interaction layer n n Interface to clients Receive requests and transform it Forward request to processing layer for processing Respond to clients Interaction Layer Processing Layer 37

Layered Application Design n Processing layer n n n business logic process Access database Integrate with EIS 38

Why Layered? n Clearly divide responsibilities n n De-couple business logic from presentation Change in business logic layer does not affect the presentation layer and vice-versa 39

MVC Pattern Model -Encapsulates application state -Responds to state queries -Exposes application functionally -Notifies views of changes State Query State Change Notification View -Renders the model -Requests updates from models -Sends user gestures to controller -Allow controller to select view View Selection User Gestures Controller -Defines Application behavior -Maps user action to model updates -Select view for response -One for each functionality Method Invocations Events 40

Three Logical Layers in a Web Application: Model n Model (Business process layer) n n Models the data and behavior behind the business process Responsible for actually doing: n n Performing DB queries Calculating the business process Processing orders Encapsulate of data and behavior which are independent of presentation 41

Three Logical Layers in a Web Application: View n View (Presentation layer) n n n Display information according to client types Display result of business logic (Model) Not concerned with how the information was obtained, or from where 42

Three Logical Layers in a Web Application: Controller n Controller (Control layer) n n 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. n n 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 43

Web Applications n n n 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 44

1 Request B R O W S E R JSP Pages 4 Response 2 Java Bean Servlet Container 3 Enterprise Information System()EIS 45

Page-centric Architecture n Composed of a series of interrelated JSP pages n JSP pages handle all aspects of the application presentation, control, and business process n Business process logic and control decisions are hard coded inside JSP pages n n in the form of Java. Beans, scriptlets, expression Next page selection is determined by n n 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"> 46

Page-centric Architecture Menu. jsp Catalog. jsp Checkout. jsp Database Page-Centric Catalog Application 47

Pipe-and-Filter Architecture n 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. 48

Diagram Pipe Filter Pipe 49

Example n n n 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. 50

Diagram Source Text Lexical Analysis Token 1 Token 2. . Syntax Analysis X = x + 1 ; Code Generation Semantic Analysis Target Code Type checked parse tree = x + x=x+1; x 1 Parse tree 51

Domain of F & P n n Problem can be divided into a sequence of processing steps over data stream. The data format transformation in each filter is well defined. 52

Advantages: n n n 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. 53

Disadvantages: n n n 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. 54

Event-Based Architecture Subscribe(register) Event Sink 1 Event Source Publish(broadcast) Event Sink 2 n 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. 55

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

Advantages: n n 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. 57

Disadvantages: n n n components relinquish control over the computation performed by the system exchange of data reasoning about correctness can be problematic. 58

Diagram Action. Listener buttom Action. Listener action. Performed() 59

Implementation import java. applet. *; import java. awt. event. *; public class clicker extends Applet implements Action. Listener{ Text. Field text 1; Button button 1; public void init(){ text 1=new Text. Field(20); add(text 1); button 1=new Button(“Click Me”) add(button 1); button 1. add. Action. Listener(this); } public void action. Performed(Action. Event event){ String msg=new String(“Welcome to Java”); if(event. get. Source()==button 1){ text 1. set. Text(msg); } } } 60

Java Event Implementation Interface Runnable Interface (thread) Event. Listener Implements Event Source add. Event. Listener() Event Sink 1 remove. Event. Listener() handle. Event 1 (Event. Object) event. Trigger() Vector V 0 1 … scan n-1 Event Sink 2 handle. Event 2 (Event. Object) 61

Java Event Implementation n All events subclass Event. Object class All GUI event subclass of AWTEvent. Listener public interface My. Listener extends Event. Listener {void handle. Event(Event. Object e); } 62

Event. Object public class My. Event. Object extends Event. Object { long t 1; public My. Event. Object(Object o){ super(o); t 1=System. current. Time(); } public long get. Time(){ return t 1; } } 63

Event Sink: public class Sink implements My. Listener{. . . public void handle. Event(Event. Object e) { System. out. println("Time is"+ e. get. Time()); } . . . . } 64

Event Source public class Source implements Runnable{ Vector v=new Vector(); Thread thread; public Source(){Thread=new Thread(this); thread. start(); }. . . public void run() { while(true) {trigger. Event(); try{thread. sleep(1000); } catch (Exception e){} } } 65

Event Source public synchronized void add. My. Listener (My. Listener l) { v. add. Element (l); } void trigger. Event() { My. Event. Object meo=new My. Event. Object (this); for(int i=0; i<v. length; i++) My. Listener wl=v. element. At(i); wl. handle. Event(meo); } 66

Registration strap main() { Source s 1=new Source(); Sink t 1=new Sink(); s 1. add. My. Listener(t 1); . . } 67

Data-Centered Architecture Style n n 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 68

Repository n n Repository vs. Filter & Pipe Example 1 flow control token lexical syntactic flow control semantic code generation parse tree 69

Repository n Example 2: n n Web service WSDL Repository Example 3: n n Contd. CORBA Interface Repository (IR) Advantage: n n n 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 70

Repository n Contd. Disadvantage: n n n More overhead in distributed application Need to be scalable Security issue Availability issue Change Repository, evolution is difficult Potential slow problem 71

Contd. Repository n Example CASE TOOL heater Design Analyzer heat start set temperature panel Design Editor reset start Report Generation cooling Air Conditioner Program Editor Code Generation 72

Repository n n 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. 73

Interpreter Style n n n 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. 74

Diagram Fetch next code exec Determine next code 75

Diagram data input output program state interpreter engine pseudo program interpreter state 76

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

Process Control Style n n n 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. 78

Process Control Style n n n 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. 79

Feedback control close loop control model Thermostat Temperature change Temperature sensor Request service Turned on or off Heating or Cooling Device 80

Feedback control close loop control model Input variable Controller process Goal Manipulated variables Controlled variable 81

Feed Forward Control Input variable process Goal Manipulated variables Controlled variable Controller 82