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 business–use - case • Select architecture style (component, link ) • Communicating architecture to stakeholders (prototypes) • Evaluate architecture • Implementation architecture - detail design

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

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. Data Yes No 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. interface interface interface Student Course Catalog Faculty 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. breach bridging breach Layered Architecture Contd. • Breach may cause deadlock. Callback technique can be used to avoid it.

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

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

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. 1 Request JSP Pages 4 Response 2 B R O W S E R 3 Java Bean Servlet Container 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. <A HERF="find.jsp> • Through the action of submitting a form, e.g. <FORM ACTION="search.jsp">

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

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