Software Architecture
1 like335 views
This document provides an agenda and overview for a two-day training on software architecture. Day 1 will cover defining software architecture, decomposition strategies like layers and tiers, and service-level requirements. Day 2 will discuss technologies used in different tiers, integration, security, and other topics. Ground rules are provided for the training. The document then defines software architecture and the differences between architecture, design, and coding. Common decomposition strategies and architectural drivers are also outlined.
Software Architecture
- 2. Agenda (Day 1) âą Defining Software Architecture âą Architecture Decomposition â Decomposition Strategies â Tiers â Layers âą Service-Level Requirements (SLRs) â List of SLRs â Impact of Dimensions on SLRs â Common Practices for Improving SLRs
- 3. Agenda (Day 2) âą Technologies used in Tiers: â Client Tier Technologies â Web/Presentation Tier Technologies â Business Tier Technologies âą Integration and Messaging âą Security âą Topics we did not cover âą Software Architecture Document âą Workshop
- 4. Rules âą Phones silent âą No laptops âą Questions/Discussions at anytime welcome âą 10 minute break every 1 hour
- 6. What is Software Architecture?(1/2) Architecture can be summarized as being about structure. Itâs about the decomposition of a product into a collection of components/modules and interactions. This needs to take into account the whole of the product, including the foundations and infrastructure services that deal with cross-cutting concerns such as security/configuration/error handling (for a piece of software).
- 7. What is Software Architecture?(2/2) Architecture is a set of structuring principles that enables a system to be comprised of a set of simpler systems each with its own local context that is independent of but not inconsistent with the context of the larger system as a whole Both definitions focus on system structure
- 8. Difference between Design and Architecture âą Architecture is about the what and where âą Design is about the how
- 9. Difference between Design and Architecture âAll architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of changeâ Grady Booch
- 10. Difference between Architecture/Design and Coding âą Architecture and Design are not coding, coding is not design nor architecture âą Even when detailed procedural designs are created for program components, the level of abstraction of the design model is higher than source code
- 12. Architectural Drivers âą Functional Requirements: â The system shall provide a facility to display the current account balance âą Software Quality Attributes: â The balance should appear within 1 minute âą Constraints: â The system must be developed using Java technologies
- 13. Seven Layers of Architecture âą Global Architecture -> Standards (e.g. OSI model) âą Enterprise Architecture -> System of Systems âą System Architecture -> Architecture Styles âą Application Architecture -> Subsystems âą Macro-Architecture -> Frameworks âą Micro-Architecture -> Design Patterns âą Objects -> Idioms (Do and Donâts)
- 14. Architectâs Responsibilities âą Find and monitor architectural drivers âą Determine architectural significance âą Perform technology and teaming selections âą Devise the big picture âą Evaluate the architecture âą Evolve the architecture âą Sell the architecture âą Communicate the architecture âą Guard the architecture âą Program and review code âą Harvest and communicate idiomatic patters
- 17. Decomposition Strategies âą Decomposition can be broken down into ten basic strategies: â Group 1 â Layering or Distribution â Group 2 â Exposure, Functionality, or Generality â Group 3 â Coupling and Cohesion or Volatility â Group 4 â Configuration â Group 5 â Planning and Tracking or Work Assignment âą For any strategies that are grouped together, you choose one of the strategies and then move on to the next grouping
- 18. Group 1 - Layering âą Layering decomposition is some ordering of principles, typically abstraction âą The layers may be totally or partially ordered âą Layering can be by layers or tiers, as explained later
- 19. Group 1 - Distribution âą Distribution is a primary technique for building scalable systems âą Distribution is among computational resources
- 20. Group 2 - Exposure âą Exposure decomposition is about how the component is exposed and consumes other components âą Any given component fundamentally has three different aspects: â Services deals with how other components access this component â Logic deals with how the component implements the work necessary to accomplish its task â Integration deals with how it accesses other components services
- 21. Group 2 - Functionality âą Functionality decomposition is about grouping within the problem space. That is, order module or customer module.
- 22. Group 2 - Generality âą Generality decomposition is determining whether you have a reusable component that can be used across many systems âą Be careful not to make assumptions that a component may be used by another system in the future and build a reusable component for a requirement that does not exist yet
- 23. Group 3 - Coupling and Cohesion âą Cohesion o the degree to which the elements of a module belong together âą Coupling o is the manner and degree of interdependence between software modules âą What we want is High Cohesion and Low/Loose Coupling
- 24. Group 3 - Volatility âą Volatility decomposition is about isolating things that are more likely to change âą For example, GUI changes are more likely than the underlying business rules
- 25. Group 4 - Configuration âą Configuration decomposition is having a target system that must support different configurations, maybe for security, performance, or usability âą Itâs like having multiple architectures with a shared core, and the only thing that changes is the configuration
- 26. Group 5 - Planning and Tracking âą Planning and Tracking decomposition is an attempt to develop a fine-grained project plan that takes into account: â Ordering is understanding the dependencies between packages and realizing which must be completed first â Sizing is breaking down the work into small- enough parts so you can develop in a iterative fashion without an iteration taking several months
- 27. Group 5 â Work Assignment âą Work Assignment decomposition is based on various considerations, including physically distributed teams, skill-set matching, and security areas
- 28. Group 5 â Work Assignment Conwayâs Law: organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations Melvin Conway 1967
- 29. TIERS
- 30. What is a Tier? âą A tier can be logical or physical organization of components into an ordered chain of service providers and consumers âą Components within a tier typically consume the services of those in an âadjacentâ provider tier and provide services to one or more âadjacentâ consumer tiers
- 31. Tiers in Architecture âą Client âą Web/Presentation âą Business âą Integration âą Resource
- 32. 2 Tier Architecture âą Also called Client-Server Architecture Server Clients Protocol
- 33. 3/Multi Tier Architecture âą Typically has a Client/Presentation Tier, Business Tier and Database Tier
- 35. LAYERS
- 36. What is a Layer? âą A layer is the hardware and software stack that hosts services within a given tier âą Layers, like tiers, represent a well-ordered relationship across interface-mediated boundaries âą Whereas tiers represent processing chains across components, layers represent container/component relationships in implementation and deployment of services
- 37. Example
- 38. Typical Layers in Architecture Networking Infrastructure Compute and Storage Enterprise Services (OS and VM) Virtual Platform (APIs) Application
- 39. Strict an relaxed layering âą Strict layering is where each layer use only APIs offered by the one layer beneath it âą Relaxed layering is where each layer may use APIs offered by any layer beneath it
- 41. Service Level Requirements (SLRs) âą Also called Non-Functional Requirements or Software Quality Attributes âą Also called xabilities or ilities
- 42. List of SLRs (1/4) âą Performance: â Response Time âą Scalability: â Increasing load without changing the system â Vertical Scalability â Horizontal Scalability âą Reliability: â Integrity â Consistency
- 43. List of SLRs (2/4) âą Availability: â System is always accessible âą Extensibility: â Add/modify functionalities without impacting existing system functionalities âą Maintainability: â The ability to correct flaws in the existing functionality without impacting other components of the system
- 44. List of SLRs (3/4) âą Manageability: â The ability to manage the system to ensure the continued health of a system with respect to scalability, reliability, availability, performance, and security â Deals with system monitoring of the QoS requirements and the ability to change the system configuration to improve the QoS dynamically without changing the system
- 45. List of SLRs (4/4) âą Security: â The ability to ensure that the system cannot be compromised â Key concepts: âą Integrity âą Availability âą Confidentially âą Non-repudiation
- 46. Impact of Dimensions on SLRs âą As you are creating your architecture, you can think of the layout of an architecture (tiers and layers) as having six independent variables that are expressed as dimensions: â Capacity â Redundancy â Modularity â Tolerance â Workload â Heterogeneity
- 47. Capacity âą The capacity dimension is the raw power in an element, perhaps CPU, fast network connection, or large storage capacity âą Capacity is increased through vertical scaling âą Capacity can improve performance, availability, and scalability
- 48. Redundancy âą The redundancy dimension is the multiple systems that work on the same job, such as load balancing among several web servers âą Redundancy is increased through horizontal scaling âą Redundancy can increase performance, reliability, availability, extensibility, and scalability âą It can decrease manageability and security
- 49. Modularity âą The modularity dimension is how you divide a computational problem into separate elements and spread those elements across multiple computer systems âą Modularity can increase scalability, extensibility, maintainability, and security âą It can decrease performance, reliability, availability, and manageability
- 50. Tolerance âą The tolerance dimension is the time available to fulfill a request from a user âą Tolerance can increase performance, scalability, reliability, and manageability
- 51. Workload âą The workload dimension is the computational work being performed at a particular point within the system âą Workload is closely related to capacity in that workload consumes available capacity, which leaves fewer resources available for other tasks âą Workload can increase performance, scalability, and availability
- 52. Heterogeneity âą The heterogeneity dimension is the diversity in technologies that is used within a system or one of its subsystems âą Heterogeneity can increase performance and scalability âą It can decrease performance, scalability, availability, extensibility, manageability, and security
- 53. Common Practices for Improving SLRs âą Redundancy: â Load Balancing â Failover â Clustering âą Availability: â Active replication: is performed by processing the same request at every replica â Passive replication: involves processing each single request on a single replica and then transferring its resultant state to the other replicas âą Performance: â Increase system capacity â Increase computational efficiency
- 55. Common Practices for Improving SLRs âą Extensibility: â Clearly define the scope in the service-level agreement â Anticipate expected changes â Design a high-quality object model âą Scalability: â Vertical Scalability: more processors, memory, and disks â Horizontal Scalability: more servers
- 56. Common Practices for Improving SLRs âą Reliability: â Increase computational efficiency â Transactions â Monitor and restart â Redundancy â Degradation â Bound execution time
- 57. TECHNOLOGIES USED IN TIERS
- 58. Client Tier Technologies âą Java AWT and Swings âą Java Applets âą Android SDK âą HTML/CSS/JS
- 59. Web/ Presentation Tier Technologies âą JSPs and Servlets âą JSF âą Spring MVC âą Thymleaf âą Velocity âą Freemarker
- 60. Business Tier Technologies âą Spring âą EJBs
- 62. System Integration Choices Style Share what? Good Bad Examples Remote Procedure Call Functionality Less Complex High Coupling Less Reliability RMI Corba File Transfer/Shar ed File Data Loose Coupling Less Timely Shared Database Data Timely High Coupling Messaging Both Loose Coupling Timely Middleware dependency SOAP REST JMS *MQ
- 63. Messaging âą Channel (Queue): Virtual pipe between sender and receiver âą Message: Atomic unit of data âą Endpoint: Gateway of each system or application to the messaging infrastructure
- 65. Message Interaction Types âą Request-driven interaction: A client requests a service from a server and waits for the response âą Event-driven interaction: An agent publishes an event about a happening. Interested subscribers receive the event and may choose to act accordingly
- 66. Common Integration Technologies âą JDBC âą JCA âą JAX-WS âą JMS âą ActiveMQ âą RabbitMQ âą Apache Camel âą Spring Integration
- 67. SECURITY
- 68. Terminology âą Principal: is an entity (a person or system that can be uniquely identified) that can be authenticated by a security module before system access is allowed or denied âą Credential: is a container of information used to authenticate a principal (e.g. username and password) âą Authentication and Authorization
- 69. Application Security âą Authentication and authorizationâUsing credentials âą Message-level data integrityâUsing XML signatures âą Message-level and transport confidentialityâUsing encryption (SSL)
- 70. Defining Security behavior âą Declarative (e.g. Spring Security configurations) âą Programmatic (e.g. isUserInRole in JEE)
- 71. What a Security Model should contain? âą Underlying system infrastructure (hardware, including the networking layer and components) âą User authentication âą User authorization âą Auditing âą Data encryption âą System hardening against specific attacks
- 72. Common Security Threats âą Man in the middle attacks âą Session hijacking (replaying data) âą Password cracking âą Phishing âą Social hacking/engineering âą Network sniffing âą Cross-site scripting âą SQL Injection âą Denial-of-service
- 73. Common Technologies âą Java Authentication and Authorization Service (JAAS) âą Spring Security âą LDAP Servers (e.g. OpenLDAP) âą Apache Shiro
- 74. TOPICS WE DID NOT COVER
- 75. Topics we did not cover âą Documenting Architecture using UML âą Design Patterns âą Architecting for the Cloud: â Resource Pooling â Rapid Elasticity â Multi-tenancy
- 77. Software Architecture Document 1. Front Page 2. Motivation and purpose 3. Product overview 4. Architectural drivers 5. Technology selection and rationale 6. Main architectural decisions and rationale 7. Naming and coding standards 8. Module view 9. Module catalogue 10. Components and connectors view (C&C) 11. Relevant allocations view 12. Module and Layer API 13. C&C Proto 14. Idiomatic Design Patterns 15. Volatilities and weaknesses 16. Glossary of terms 17. References