Software Engineering Architectural Design PDF

Chapter 6 Architectural Design CSC3324 Dr Houda CHAKIRI Copyright © 2016, 2011, 2006 Pearson Education, Inc. All Rights Reserved  Learning Objectives Architectural design decisions Architectural...

Chapter 6 Architectural Design CSC3324 Dr Houda CHAKIRI 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 communicating components. Architectural 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: Order Processing System Architectural C1 : Product Catalog C2 : Online Store C2: Payment Gateway complexity Complexity in a system architecture arises because of the C1: Customer number and the Profile nature of the Management relationships C2: Order between History components in that system. Examples of C1: Inventory Management component C2: Order Management 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 visible properties of the sub- Icons (boxes) connected with systems. lines However, useful for No rules governing formation communication with Used for both static and dynamic stakeholders and for Modeling project planning. Good idea to include a 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 phrases for actions)  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 developed. However, a number of common decisions span all design 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 users. If you get these wrong, your product is unlikely to be a commercial success. Some characteristics are contradictory, so you can only optimize The the most important. importance of architectural design issues 23  Product lifetime: If you anticipate a long product lifetime, you will need to create regular product revisions. You therefore need an architecture that is evolutive, so that it can be adapted to accommodate new The features and technology. importance of architectural design issues 24  Software reuse: You can save a lot of time and effort, if you can reuse large components from other The products or open-source software. However, this constrains your importance architectural choices because you must of fit your design around the software that is being reused. architectura l design issues 25  Number of users: If you are developing consumer software delivered over the Internet, the number of users can change very quickly. This can lead to serious performance degradation The unless you design your architecture so importance of that your system can be quickly scaled up and down. architectural design issues(cont.) 26  Software compatibility: For some products, it is important to maintain compatibility with other software so that users can adopt your product and use data prepared using a different The system. This may limit architectural importance of choices, such as the database software that you can use. architectural design issues (cont.) 27  Human and organizational factors The planned schedule to bring the product to market The The capabilities of your development team importance of The software development budget. architectural 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  Maintainability vs. Performance Architectural Security vs. design Usability trade-offs Availability vs. Time to market and cost. Trade off #1: Maintainability vs Performance Maintainability Performance Self contained parts (components) Few components means better easy to replace performance takes time for components to There may be delays involved in communicate with each other. transferring data 30 Trade off #2: Security vs Usability Security Usability Design the system protection Interaction with the system is as a series of layers. inevitably slowed by its security features. If one of these components is Users must remember compromised by an attacker, information, like passwords, that then the other layers remain is needed to penetrate a security intact. layer. 31 Authentication layers To avoid this, you need an architecture that: Doesn’t have too many security layers, Doesn’t enforce unnecessary security Provides helper components that reduce the load on users. 32 Trade off #3: Availability vs time-to-market Availability Time to Market You achieve availability by having Implementing extra components takes redundant components in a system. time and increases the cost of system development. You include sensor components Adds complexity to the system that detect failure Switching components that switch Increases the chances of introducing operation to a redundant bugs and vulnerabilities. component when a 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 network. For both design and documentation, you usually need 4+1 View Model to present multiple views of the software architecture. In class practice Draft a component diagram for your case study. Identify the main components, define the interfaces they provide and require, and show the relationships and dependencies between them. This diagram should reflect how different parts of your system interact to fulfill the use cases you have previously worked on. Be prepared to present and discuss your draft. 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 MVC 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 Organization of the Model-View- Controller Web Application Architecture Using the MVC 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 adjacent 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. Disadvantages In practice, providing a clean separation between layers is often 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 Architecture of a Data Retrieval System  A generic layered Architectural architecture for a Design web-based Guidelines application in a layered architecture Each layer is an area of concern and is Ideally, components at considered level X (say) should only separately from interact with the APIs of other layers. the components in level X-1; that is, interactions The should be between components are layers and not across independent layers. and do not overlap in functionality. 47 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. 49  Monolithic Architecture (single deployment unit) Architectural structures Distributed Architecture (multiple deployment units, usually consisting of services) 50  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 Architecture 52 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 web pages to the manages the system browser for rendering and data and transfers processes HTTP requests these data to and from from the client. the system database. responsible for application-specific operations. 55  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 Architecture 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 architecture may be more appropriate. 67 Technology Choices Database Platform Should you use a relational SQL Should you deliver your product database or an unstructured on a mobile app and/or a web NOSQL database? platform? 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? 68 Technology Choices (cont.) Development Tools Open Source Do your development tools Are there suitable open-source embed architectural components that you could assumptions about the software incorporate into your products? being developed that limit your architectural choices? 69 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. 70 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. 71 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. 72 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. 73 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. 74