Software Engineering Textbook - Architectural Design PDF

Chapter 6 Architectural Design CSC3324 Copyright © 2016, 2011, 2006 Pearson Education, Inc. All Rights Reserved  Learning Objectives Architectural design decisions Architectural views Architectural patterns Applica...

Chapter 6 Architectural Design CSC3324 Copyright © 2016, 2011, 2006 Pearson Education, Inc. All Rights Reserved  Learning Objectives Architectural design decisions Architectural views Architectural patterns Application architectures  Software Architecture To create a reliable, secure and efficient product, you need to pay attention to architectural design which includes: The overall organization, How the software is decomposed into components, The server organization The technologies that you use to build the software. 3 The IEEE definition of software architecture “Architecture is the fundamental organization of a software system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.” 4  Architectural Design Architectural design is concerned with understanding how a software system should be organized and designing the overall structure of that system. The Architecture of a Packing Robot Control System Architectural Design Architectural design is the critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them. The output of the architectural design process is an architectural model that describes how the system is organized as a set of Architectura l Design Process  Software Architecture Document Product Overview—Product vision, stakeholders, target market, etc. Architectural Models—Specification using various models, both static and dynamic. Mapping Between Models—Tables and text relating models Architectural Design Rationale— Explanation of difficult, crucial, puzzling, and hard-to-change design decisions  Architectural Abstraction Architecture in the small is concerned with the architecture of individual programs. At this level, we are concerned with the way that an individual program is decomposed into components. Architecture in the large is concerned with the architecture of complex enterprise systems that include other systems, programs, and program components. These enterprise systems are distributed over different computers, which may be owned and managed by different companies.  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 The architecture may be reusable across a range of systems Product-line architectures may be developed. Notations for Architectural Specifications  C1 : Product Catalog C1: Order Processing System Architectural C2 : Online Store C2: Payment Gateway complexity Complexity in a system architecture C1: Customer arises because of Profile the number and Management the nature of C2: Order History the relationships between C1: Inventory Management components in C2: Order Management that system. Examples of component relationships: 12 Architectural Modeling Notations Several notations for architectural modeling: Box-and-line diagrams UML component diagrams UML package diagrams UML deployment diagrams  Box and Line Diagrams Very abstract - they do not show the nature of component relationships nor the externally Icons (boxes) connected visible properties of with lines the sub-systems. No rules governing However, useful for formation communication Used for both static and with stakeholders dynamic Modeling and for project Good idea to include a planning. legend Box-and-Line Diagram Example 1. Make box-and-line diagrams only when no standard notation is adequate. 2. Keep the boxes and lines simple. 3. Make symbols for different things look different. 4. Use symbols consistently in different diagrams. 5. Use grammatical conventions to name elements (noun phrases for things and verb  Component diagrams (UML) A Component-Based Diagram, is a type of structural diagram in the Unified Modeling Language (UML) that visualizes the organization and interrelationships of the components within a system. Components are modular parts of a system that encapsulate implementation and expose a set of interfaces. These diagrams illustrate how components are wired together to form larger systems, detailing their dependencies and interactions. Component-Based Diagrams are widely used in system design to promote modularity, enhance understanding of system architecture. Component-Based Diagram Elements Components Interfaces Relationships Ports Artifacts Nodes Steps to Create a Component-Based Diagrams 1. Identify the System Scope and Requirements 2. Identify and Define Components 3. Identify Provided and Required Interfaces 4. Identify Relationships and Dependencies 5. Identify Artifacts 6. Identify Nodes 7. Draw the Diagram Architectural Design Decisions Architectural design is a creative process so the process differs depending on the type of system being However, a number of common decisions span all design developed. processes and these decisions affect the non-functional characteristics of the system. Architecture Reuse Systems in the same domain often have similar architectures that reflect domain concepts. Application product lines are built around a core architecture with variants that satisfy particular customer requirements. The architecture of a system may be designed around one of more architectural patterns or ‘styles’. These capture the essence of an architecture and can be instantiated in different ways. Why Architecture is important? Architecture is important because the architecture of a system has a fundamental influence on its non-functional properties. Performance: Localize critical operations and minimize communications. Use large rather than fine-grain components. Security: Use a layered architecture with critical assets in the inner layers. Safety: Localise safety-critical features in a small number of sub-systems. Availability: Include redundant components and mechanisms for fault tolerance. Maintainability: Use fine-grain, replaceable components. Issues that influence architectural decisions 22  Nonfunctional product characteristics: Security and performance affect all The users. If you get these wrong, your product is unlikely to be a importanc commercial success. Some characteristics are contradictory, e of so you can only optimize the most architectur important. al design issues 23  Product lifetime: If you anticipate a long product lifetime, you will need to create The regular product revisions. You therefore need an architecture importance that is evolutive, so that it can be of adapted to accommodate new features and technology. architectur al design issues 24  Software reuse: You can save a lot of time and effort, if you can reuse large components from other products or open-source The software. However, this constrains importan your architectural choices because you must fit your design ce of around the software that is being architectu reused. ral design issues 25  If you are developing consumer software delivered over the The Internet, the number of users can change very quickly. This can lead importance to serious performance of degradation unless you design your architecture so that your architectura system can be quickly scaled up l design and down. issues(cont. ) 26  Software compatibility: For some products, it is important to maintain compatibility with other The software so that users can adopt importance your product and use data prepared using a different system. This may of limit architectural choices, such as architectura the database software that you can use. l design issues (cont.) 27  Human and organizational factors The planned schedule to bring The the product to market importance The capabilities of your of development team architectura The software development budget. l design issues If you choose an architecture that (cont.) requires your team to learn unfamiliar technologies, then this may delay the delivery of your system. There is no point in creating a “perfect” architecture that is delivered late if this means that a competing product captures the market. 28  29 Maintainability vs. Performance Architectur Security vs. al design Usability trade-offs Availability vs. Time to market and cost. Trade off #1: Maintainability vs Performance Maintainability Performance Self contained parts Few components means (components) easy to replace better performance takes time for components to There may be delays involved communicate with each other. in transferring data 30 Trade off #2: Security vs Usability Security Usability Design the system Interaction with the system is protection as a series of inevitably slowed by its layers. security features. If one of these Users must remember components is information, like passwords, compromised by an that is needed to penetrate a attacker, then the other security layer. layers remain intact. 31 Authenticati on layers To avoid this, you need an architecture that: Doesn’t have too many security layers, Doesn’t enforce unnecessary security 32 Trade off #3: Availability vs time- to-market Availability Time to Market You achieve availability by Implementing extra components having redundant components takes time and increases the cost in a system. of system development. You include sensor Adds complexity to the system components that detect failure Switching components that Increases the chances of switch operation to a introducing bugs and redundant component when a vulnerabilities. failure is detected. 33 Architectural Design Decisions Architectural Views Copyright © 2016, 2011, 2006 Pearson Education, Inc. All Rights Reserved  Architectural Views What views or perspectives are useful when designing and documenting a system’s architecture? What notations should be used for describing architectural models? Each architectural model only shows one view or perspective of the system. It might show how a system is decomposed into modules, how the run-time processes interact or the different ways in which system components are distributed across a 4+1 View Model network. For both design and documentation, you usually need to present multiple Architectural Patterns Copyright © 2016, 2011, 2006 Pearson Education, Inc. All Rights Reserved Architectural Patterns Patterns are a means of representing, sharing and reusing knowledge. An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments. Patterns should include information about when they are and when the are not useful. Patterns may be represented using tabular and graphical descriptions. The Model-View-Controller (M V C) Pattern Name MVC (Model-View-Controller) Description Separates presentation and interaction from the system data. The system is structured into three logical components that interact with each other. The Model component manages the system data and associated operations on that data. The View component defines and manages how the data is presented to the user. The Controller component manages user interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions to the View and the Model. See Figure 6.3. Example Figure 6.4 shows the architecture of a web-based application system organized using the M VC pattern. When used Used when there are multiple ways to view and interact with data. Also used when the future requirements for interaction and presentation of data are unknown. Advantages Allows the data to change independently of its representation and vice versa. Supports presentation of the same data in different ways with changes made in one representation shown in all of them. Disadvantages Can involve additional code and code complexity when the data model and interactions are simple. The Organizati on of the Model- View- Controller Web Applicatio n Architectu re Using the M V C Pattern  Layered Architecture Layered software architectures comprise multiple layers of components that are placed into logical groupings based on the type of functionality they provide or based on their interactions with other components, such that interlayer communication occurs between layers. Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected. The Layered Architecture Pattern Name Layered architecture Description Organizes the system into layers with related functionality associated with each layer. A layer provides services to the layer above it so the lowest-level layers represent core services that are likely to be used throughout the system. See Figure 6.6. Example A layered model of a system for sharing copyright documents held in different libraries, as shown in Figure 6.7. When used Used when building new facilities on top of existing systems; when the development is spread across several teams with each team responsibility for a layer of functionality; when there is a requirement for multi-level security. Advantages Allows replacement of entire layers so long as the interface is maintained. Redundant facilities (e.g., authentication) can be provided in each layer to increase the dependability of the system. Disadvantag In practice, providing a clean separation between layers is often es difficult and a high-level layer may have to interact directly with lower-level layers rather than through the layer immediately below it. Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer. The Architectu re of a Data Retrieval System  A generic layered Architectur architecture al Design for a web- Guidelines based in a layered application architectur e Each layer is an area of concern and Ideally, is considered components at separately level X (say) from other should only layers. interact with the The APIs of the components components in are level X-1; that is, independent interactions should and do not be between layers overlap in 46 Comparison of Closed vs. Open Layered Architecture  Cross-cutting concerns are concerns that are systemic. i.e.: they affect the whole system. The existence of cross-cutting concerns is the reason why modifying a system after it has been designed to improve its security is often difficult. Cross- Cutting Concerns In a layered architecture, cross- cutting concerns affect all layers in the system as well as the way in which people use the system. 48  Monolithic Architecture (single deployment unit) Architectur al structures Distributed Architecture (multiple deployment units, usually consisting of services) 49  Client-Server Architecture Distributed system model which shows how data and processing is distributed across a range of components. Can be implemented on a single computer. Set of stand-alone servers which provide specific services such as printing, data management, etc. Set of clients which call on these services. Network which allows clients to access servers. Client- Server Architectur e 51 A Client-Server Architecture for a Film Library 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. Multi-tier client-server architecture communicates with clients using the HTTP protocol. It delivers manages the web pages to the system data and browser for rendering transfers these data and processes HTTP to and from the requests from the system database. client. responsible for application-specific operations. 54  Application Architectures Copyright © 2016, 2011, 2006 Pearson Education, Inc. All Rights Reserved Application Architectures Application systems are designed to meet an organisational need. As businesses have much in common, their application systems also tend to have a common architecture that reflects the application requirements. A generic application architecture is an architecture for a type of software system that may be configured and adapted to create a system that meets specific requirements.  Use of Application Architectures As a starting point for architectural design. As a design checklist. As a way of organizing the work of the development team. As a means of assessing components for reuse. As a vocabulary for talking about application types.  Examples of Application Types Data processing applications Data driven applications that process data in batches without explicit user intervention during the processing. Transaction processing applications Data-centred applications that process user requests and update information in a system database. Event processing systems Applications where system actions depend on interpreting events from the system’s environment. Language processing systems Applications where the users’ intentions are specified in a formal language that is processed and interpreted by the system.  Application Type Examples Two very widely used generic application architectures are transaction processing systems and language processing systems. Transaction processing systems E-commerce systems; Reservation systems. Language processing systems Compilers; Command interpreters. Transaction Processing Systems Process user requests for information from a database or requests to update the database. From a user perspective a transaction is: Any coherent sequence of operations that satisfies a goal; For example - find the times of flights from London to Paris. Users make asynchronous requests for service which are then processed by a transaction manager. The Software Architecture of an A T M System  Information Systems Architecture Information systems have a generic architecture that can be organized as a layered architecture. These are transaction-based systems as interaction with these systems generally involves database transactions. Layers include: The user interface User communications Information retrieval System database The Architect ure of the Mentcare System Web-Based Information Systems Information and resource management systems are now usually web-based systems where the user interfaces are implemented using a web browser. For example, e-commerce systems are Internet-based resource management systems that accept electronic orders for goods or services and then arrange delivery of these goods or services to the customer. In an e-commerce system, the application-specific layer includes additional functionality supporting a ‘shopping cart’ in which users can place a number of items in separate transactions, then pay for them all together in a single transaction.  Server Implementation These systems are often implemented as multi-tier client server/architectures The web server is responsible for all user communications, with the user interface implemented using a web browser; The application server is responsible for implementing application-specific logic as well as information storage and retrieval requests; The database server moves information to and from the database and handles transaction management.  Issues in Architectural Choice Data type and data updates When using structured data that may be updated by different system features, better to have a single shared DB that provides locking and transaction management. If data is distributed across services, you need a way to keep it consistent and this adds overhead to your system. Change frequency If you anticipate that system components will be regularly changed or replaced, then isolating these components as separate services simplifies those changes. System execution platform If you plan to run your system on the cloud with users accessing it over the Internet, best implement it as a SOA because scaling the system is simpler. If your product is a business system that runs on local servers, a multi-tier 66 architecture may be more appropriate. Technology Choices Database Platform Should you use a relational Should you deliver your SQL database or an product on a mobile app unstructured NOSQL and/or a web platform? database? Server Should you use dedicated in-house servers or design your system to run on a public cloud? If a public cloud, should you use Amazon, Google, Microsoft, or some other option? 67 Technology Choices (cont.) Development Tools Open Source Do your development tools Are there suitable open- embed architectural source components that assumptions about the you could incorporate into software being developed your products? that limit your architectural choices? 68 Database There are two kinds of database that are now commonly used: Relational databases NoSQL databases, in which the data has a more flexible, user-defined organization. Relational databases, such as MySQL, are particularly suitable for situations where you need transaction management, and the data structures are predictable and simple. NoSQL databases, such as MongoDB, are more flexible and potentially more efficient than relational databases for data analysis. 69 Delivery Platform Delivery can be as a web-based or a mobile product or both. Mobile issues: Intermittent connectivity You must be able to provide a limited service without network connectivity. Processor power Mobile devices have less powerful processors, so you need to minimize computationally- intensive operations. Power management Mobile battery life is limited so you should try to minimize the power used by your application. On-screen keyboard On-screen keyboards are slow and error-prone. You should minimize input using the screen keyboard to reduce user frustration. 70 Server A key decision that you have to make is whether to design your system to run on customer servers or to run on the cloud. For consumer products that are not simply mobile apps I think it almost always makes sense to develop for the cloud. For business products, it is a more difficult decision. Some businesses are concerned about cloud security and prefer to run their systems on in-house servers. They may have a predictable pattern of system usage so there is less need to design your system to cope with large changes in demand. An important choice you have to make if you are running your software on the cloud is which cloud provider to use. 71 Development tools Development technologies, such as a mobile development toolkit or a web application framework, influence the architecture of your software. The development technology that you use may also have an indirect influence on the system architecture. Developers favor architectural choices that use familiar technologies that they understand. For example, if your team have a lot of experience of relational databases, they may argue for this instead of a NoSQL database. 72 Open Source Open-Source software is software that is available, which you can change and modify as you wish. The advantage is that you can reuse / implement new software  reduces development costs and time to market. The disadvantages of using open-source software: constraints to that software/ no control over its evolution. The decision on the use of open-source software depends on the availability, maturity and continuing support. Open source license issues may impose constraints on how you use the software. 73