Software Architecture PDF

Software Architecture 1  Defintions - ANSI/IEEE Std 1471-2000 “Architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” Al...

Software Architecture 1  Defintions - ANSI/IEEE Std 1471-2000 “Architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” All architecture is software design, but not all design is software architecture First stage of the design process 2 Architectural design decisions Is there a generic application architecture that can be used? How will the system be distributed? What architectural styles are appropriate? What approach will be used to structure the system? How will the system be decomposed into modules? What control strategy should be used? How will the architectural design be evaluated? How should the architecture be documented? Chapter 6 Architectural design 3  Architecture Defines Structure Decomposition of system into components/modules/subsystems Architecture defines: Component interfaces What a component can do Component communications and dependencies How components communicate Component responsibilities Precisely what a component will do when you ask it 4 Advantages of explicit architecture Stakeholder communication Architecture may be used as a focus of discussion by system stakeholders. System analysis Means that analysis of whether the system can meet its non-functional requirements is possible. Large-scale reuse (reusability) The architecture may be reusable across a range of systems Product-line architectures may be developed. Chapter 6 Architectural design 5 Quality Attribute Requirements Quality Architecture Requirement Attribute Performance Application performance must provide sub-four second response times for 90% of requests. Security All communications must be authenticated and encrypted using certificates. Resource The server component must run on a low end office-based server with 512MB memory. Management Usability The user interface component must run in an Internet browser to support remote users. Availability The system must run 24x7x365, with overall availability of 0.99. Reliability No message loss is allowed, and all message delivery outcomes must be known with 30 seconds Scalability The application must be able to handle a peak load of 500 concurrent users during the enrollment period. Modifiability The architecture must support a phased migration from the current Forth Generation Language (4GL) version to a.NET systems technology solution. 6 Constraints Constraint Architecture Requirement Business The technology must run as a plug-in for MS BizTalk, as we want to sell this to Microsoft. Development The system must be written in Java so that we can use existing development staff. Schedule The first version of this product must be delivered within six months. Business We want to work closely with and get more development funding from MegaHugeTech Corp, so we need to use their technology in our application. 7 Structure and Dependencies Excessive component C1 C2 C3 C4 C1 C2 C3 C4 dependencies are bad! Key architecture issue Identifying components AL that may change Third Party Reduce direct Component dependencies on these components Four components are directly dependent on a Third Party Component Creates more modifiable third party component. If the third party component is replaced with a new component with a different interface, changes to each Only the AL (abstraction layer) component is directly systems component are likely. Diagram Key dependent on the third party component. If the third party component is replaced, changes are restricted to the AL component only Component C Dependency 8 Coupling & Cohesion (Important for Good Design) Lower Coupling: Lower dependencies between Components Why it is good design????? Higher Cohesion Single task (responsibility) components Why it is good design????? Lower Coupling & Higher Cohesion Leads to Good Architecture, Design and Implementation 9 Architecture Specifies Component Communication Communication involves: Function calls Remote Procedure Calls (RPC) Asynchronous message Don’t wait for reply Synchronization messages Wait for reply 10 Architecture is an Abstraction Architecture provides an abstract view of a design Hides complexity of design May or may not be a direct mapping between architecture elements and software elements Example – A Marketecture informal depiction of system’s structure and interactions. portray the design philosophies embodied in the architecture Every system should have a marketecture: Easy to understand Helps discussion during design, build, review, sales (!) process 11 Marketecture Example Local information repositories Internet ICDE Repository ICDE Analyst Recording Software 3rd Party Tools 12 Decomposition Hierarchical decomposition is a Top Level Architecture Description Diagram Key Component powerful abstraction mechanism C Client Broker Server Dependency Partitions design Allocate components to development teams Security How this architecture lower coupling Message Server Handler between clients & Servers? Directory Server Request Data Handler Store How this architecture achieves higher cohesion? 13 Philippe Krutchen - 4+1 View Model Logical view: describes architecturally significant elements of the architecture and the relationships between them. Process view: describes the communications elements of an architecture. Physical view: depicts how the major processes and components are mapped on to the applications hardware. Development view: captures the internal organization of the software components as held in e.g. a configuration management tool. Architecture use cases: capture the requirements for the architecture; related to more than one particular view 14 Architectural Patterns An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context Design Patterns Works at the level of classes & relationship  Code Architectural Patterns Level of subsystems, components, external systems N-Tier Client Server Pattern Separation of concerns: Presentation, business and data Client Web Web Web handling logic are clearly partitioned Tier Client Client Client in different tiers. Synchronous communications: Web Server Web Server Communications between tiers is Tier synchronous request-reply. Each tier waits for a response from the other tier before proceeding. Business Application Server Logic Tier Opposite to asynchronies communication Data Flexible deployment: There are no Management Databases restrictions on how a multi-tier Tier application is deployed. All tiers could run on the same machine, or each tier may be deployed on its own machine. 16 The Client–server pattern Name Client-server Description In a client–server architecture, the functionality of the system is organized into services, with each service delivered from a separate server. Clients are users of these services and access servers to make use of them. Example Figure 6.11 is an example of a film and video/DVD library organized as a client–server system. When used Used when data in a shared database has to be accessed from a range of locations. Because servers can be replicated, may also be used when the load on a system is variable. Advantages The principal advantage of this model is that servers can be distributed across a network. General functionality (e.g., a printing service) can be available to all clients and does not need to be implemented by all services. Disadvantages Each service is a single point of failure so susceptible to denial of service attacks or server failure. Performance may be unpredictable because it depends on the network as well as the system. May be management problems if servers are owned by different organizations. Chapter 6 Architectural design 17 Publish-Subscribe Pattern Many-to-Many messaging: Published messages are sent to all subscribers who are Subscriber registered with the topic. Publisher Topic Subscriber Subscriber Loose Coupling: As with messaging, there is no direct binding between publishers and subscribers. 18  Pipe and Filter Pipe and Filter is a simple architectural style that connects several filters that process a stream of data, each connected to the next component in the processing pipeline via a Pipe. The pipe and filter pattern Name Pipe and filter Description The processing of the data in a system is organized so that each processing component (filter) is discrete and carries out one type of data transformation. The data flows (as in a pipe) from one component to another for processing. Example Figure 6.13 is an example of a pipe and filter system used for processing invoices. When used Commonly used in data processing applications (both batch- and transaction-based) where inputs are processed in separate stages to generate related outputs. Advantages Easy to understand and supports transformation reuse. Workflow style matches the structure of many business processes. Evolution by adding transformations is straightforward. Can be implemented as either a sequential or concurrent system. Disadvantages The format for data transfer has to be agreed upon between communicating transformations. Each transformation must parse its input and unparse its output to the agreed form. This increases system overhead and may mean that it is impossible to reuse functional transformations that use incompatible data structures. Chapter 6 Architectural design 20 Software Architecture Modeling: UML Component Diagram 21 UML Communication Diagram