Software Architecture

1. 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 a object, package, DB, API, or a subsystem • One system requirement may result in multiple architectures by different architects

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

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

4. 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 - O.S independent, risk of tight dependency • Scalability - Adaptive to volume, risk of neck bottle • Interoperability - Universal accessibility, risk of tight dependency of infrastructure

5. Architectural Attributes Contd. • Business Qualities • Time in market • Cost • Complexity • Lifetime

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

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

8. Compiler a Reference Model Reference Architecture a-b or a-c pipe & filter b Architecture Style Repository c Architecture Concept

9. Architecture Style • Virtual machines • Independent component • Data Flow • Data centered • Call & Ret • Heterogeneous. • MVC

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

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

12. 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 a ID name • Interface supports plug in and play

13. interface interface interface Student Course Catalog Faculty Subsystem Contd.

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

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

16. Partition Guideline • Coupling and cohesion • User organization • Competency and/or skill areas • System distribution • Security • Variability

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

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

19. J2EE EJB App. Web App. SOAP HTTP EJB Container Web Container TCP Transaction J2EE Server IP OSI Application Layer Presentation Layer Session Layer Transportation Layer Network Layer Data Link Layer Psychical Layer Layered Architecture Contd. • J2EE application server, SOAP Application server Web Service

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

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

22. Advantages: • Support designs based on increasing levels of abstraction. • They support enhancement: changes to the function of one layer affect at most two other layers. • They support reuse: allow different implementations of the same layer.

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

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

25. Layered Application Design • Processing layer • business logic process • Access database • Integrate with EIS

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

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

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

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

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

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

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

33. 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">

34. Page-centric Architecture Menu.jsp Catalog.jsp Checkout.jsp DataBase Page-Centric Catalog Application

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

36. P P F F F P P F P Diagram

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

38. Source Text Lexical Analysis Syntax Analysis Semantic Analysis Code Generation Target Code Token1 Token2 . . X = x + 1 ; = Type checked parse tree x + x=x+1; x 1 Parse tree Diagram

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

40. 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, deadlock. • Support concurrent execution

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

42. Subscribe(register) Event Sink1 Event Source Publish(broadcast) Event Sink2 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.

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

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

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

46. Diagram actionListener actionListener actionListener buttom actionPerformed() actionPerformed()

47. 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(){ 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); } } }

48. Java Event Implementation Interface Interface Runnable (thread) EventListener Implements Event Source addEventListener() Event Sink1 removeEventListener() handleEvent1 (EventObject) evetTrigger() Vector V 0 1 n-1 Event Sink2 … handleEvent2 (EventObject) scan

49. Java Event Implementation • All events subclass EventObject class. • All GUI event subclass of AWTEvent • EventListener public interface MyListener extends EventListener {void handleEvent(EventObject e);}

50. EventObject public class MyEventObject extends EventObject { long t1; public MyEventObject(Object o){ super(o); t1=System.currentTime(); } public long getTime(){ return t1;} }