Lecture6_Architectural Design_2024f.pdf

SWE3002-42: Introduction to Software Engineering Lecture 6 – Architectural Design Sooyoung Cha Department of Computer Science and Engineering Chapter 6. Architectural Design Topics covered 01 Architectural Design 02 Architectu...

SWE3002-42: Introduction to Software Engineering Lecture 6 – Architectural Design Sooyoung Cha Department of Computer Science and Engineering Chapter 6. Architectural Design Topics covered 01 Architectural Design 02 Architectural Design Decisions 03 Architectural Views 04 Architectural Patterns 05 Application Architectures Chapter 6. (p.168 ~ p.195) 2  Chapter 6-1. Architectural design Architectural design [About architectural design]  Designing the overall structure of a SW system.  Identifying the main structural components in a system and the relationships between them.  Designing a system organization that will satisfy the functional and non-functional requirements of a system.  Depending on the system type, the background and experience of the system architect, and the specific requirements for the system. 3  Chapter 6-1. Architectural design Architectural design [The architecture of a packing robot control system]  Block diagram Box (Boxes within boxes): A component (or sub-components) Arrow: The flow of data or control signals from component to component. 4  Chapter 6-1. Architectural design Architectural design [SW architectures at two levels of abstraction]  Architecture in the small (Today’s topic) The architecture of individual programs. Individual decomposition Components program  Architecture in the large The architecture of complex enterprise systems that include other systems, programs, and program components. 5  Chapter 6-1. Architectural design Architectural design [Three advantages for designing SW architecture]  Stakeholder communication The architecture can be used as a focus for discussion by different stakeholders.  System analysis Architectural design decisions can affect whether the system can meet critical requirements such as performance, reliability, and maintainability.  Large-scale reuse The system architecture can support large-scale software reuse. (The system architecture is often the same for systems with similar requirements.) 6  Chapter 6-2. Architectural design decisions Architectural design decisions The non-functional affect The choice of architectural requirements of the system style and structure  Non-functional requirements. Constraints on the services offered by the system. Performance Security Safety Availability Maintainability 7  Chapter 6-2. Architectural design decisions Architectural design decisions [The five non-functional requirements]  Performance Localize critical operations within a small number of components. (The same computer > distributed across the network) Reduce the number of component communications by using large components.  Security Use a layered structure for the architecture. (= Protecting the most critical assets in the innermost layers.)  Safety Reduce the costs and problems of safety validation. (e.g., Putting safety-related operations together in a single component.) 8  Chapter 6-2. Architectural design decisions Architectural design decisions [The five non-functional requirements]  Availability Include redundant components to replace and update components without stopping the system.  Maintainability Use fine-grain, self-contained components that may readily be changed. conflict Performance Maintainability 9 Chapter 6-2. Architectural design decisions Architectural design decisions 10  Chapter 6-3. Architectural design views Architectural views [Architectural views]  What views or perspectives are useful when designing and documenting a system’s architecture? The “4+1” view model1 11 1: Philippe Kruchten “Architectural Blueprints—The “4+1” View Model of Software Architecture”  Chapter 6-3. Architectural design views 4+1 view model of software architecture [4+1 view model of software architecture] which shows the key abstractions in the system as objects. A logical view (functional requirements). which shows how, at run-time, the system is composed of A process view interacting processes. (non-functional requirements: performance) A development which shows how the software is decomposed for development. view (Useful for software managers and programmers) which shows how the system HW and SW components are A physical view distributed across the processors in the system. (systems engineers) which shows the sequences of interactions between objects or Scenarios between processes. 12  Chapter 6-4. Architectural patterns Architectural patterns [Architectural patterns]  A stylized, abstract description of good practice, which has been tried and tested in different systems and environments.  Describing a system organization that has been successful in previous systems.  Including information on when it is and is not appropriate to use that pattern, and details on the pattern’s strengths and weaknesses. 13  Chapter 6-4. Architectural patterns Architectural patterns [Model-View-Controller (MVC) pattern]  Separate presentation and interaction from the system data. Model View Dogs SELECT * FROM dogs; … 2. Require Dog Data 3. Get Dog Presentation Controller 1. Get Dogs If(success) View.dogs else 4. Dogs View.error 14  Chapter 6-4. Architectural patterns Architectural patterns [Model-View-Controller (MVC) pattern]  Separates presentation and interaction from the system data.  The system is structured into three logical components that interact with each other. Model manages the system data and associated operations on that data. component View defines and manages how the data is presented to the user. component Controller manages user interaction (e.g., key presses, mouse clicks, etc.) component and passes these interactions to the View and the Model. 15  Chapter 6-4. Architectural patterns Architectural patterns [Model-View-Controller (MVC) pattern]  When used? There are multiple ways to view and interact with data. The future requirements for interaction and presentation of data are unknown.  Advantages Allow the data to change independently of its representation and vice versa. Support presentation of the same data in different ways.  Disadvantages Involve additional code and code complexity when the data model and interactions are simple. 16  Chapter 6-4. Architectural patterns Layered Architecture [Layered Architecture]  Organizing the system into layers, where each layer provides services to the layer above it. 17  Chapter 6-4. Architectural patterns Layered Architecture [Layered Architecture]  Achieving separation and independence.  Supporting the incremental development of systems. Some of the services provided by each layer are available to users. Only the adjacent layer is affected when layer interfaces change.  When used? When building new facilities on top of existing systems. When several teams develop a system and each team is responsible for a layer of functionality. When there is a requirement for multi-level security. 18  Chapter 6-4. Architectural patterns Layered Architecture [Layered Architecture]  Advantages Allowing 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 Providing a clean separation between layers is often difficult. Not interacting 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. 19  Chapter 6-4. Architectural patterns Layered Architecture [The architecture of the iLearn system] 20  Chapter 6-4. Architectural patterns Repository Architecture [Repository architecture]  All data is managed in a repository accessible to all system components.  Components do not interact directly, only through the repository. Component Repository Component Component Component Component 21  Chapter 6-4. Architectural patterns Repository Architecture [Repository architecture]  When used? When having a system in which large volumes of information are generated that has to be stored for a long time. Data-driven systems where the inclusion of data in the repository triggers an action or tool.  Advantages Components can be independent; (Don’t need to know of the existence of other components.) All data can be managed consistently as it is all in one place. 22  Chapter 6-4. Architectural patterns Repository Architecture [Repository architecture]  Disadvantages The repository is a single point of failure so problems in the repository affect the whole system. May be inefficiencies in organizing all communication through the repository. Distributing the repository across several computers may be difficult. 23 https://www.slashfilm.com/606595/the-massive-mistake-that-nearly-destroyed-toy-story-2/  Chapter 6-4. Architectural patterns Client-Server Architecture [Client-Server Architecture]  The system is presented as a set of services, with each service delivered by a separate server.  Clients (e.g., users of these services) access servers to make use of them. Client Client Client Network (e.g, Internet) Server Server Server 24  Chapter 6-4. Architectural patterns Client-Server Architecture [The major components of Client-Server Architecture]  A set of servers that offer services to other components. ex) Print servers that offer printing services. ex) File servers that offer file management services.  A set of clients that call on the services offered by servers.  A network that allows the clients to access these services. 25  Chapter 6-4. Architectural patterns Client-Server Architecture [Client-Server Architecture]  When used? Used when data in a shared DB has to be accessed from a range of locations.  Advantages 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 susceptible to denial of service (DoS) attacks or server failure. Performance problems as it depends on the network. Management problems if servers are owned by different organizations. 26  Chapter 6-4. Architectural patterns Client-Server Architecture [A client–server architecture for a film library] 27  Chapter 6-4. Architectural patterns Pipe and filter Architecture [Pipe and filter Architecture]  The processing of the data 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.  When used? Commonly used in data-processing applications where inputs are processed in separate stages to generate related outputs. $cat test.c | grep 'cha' 28  Chapter 6-4. Architectural patterns Pipe and filter Architecture [An example of the pipe and filter architecture] 29  Chapter 6-4. Architectural patterns Pipe and filter Architecture [Pipe and filter Architecture]  Advantages Easy to understand and supports transformation reuse. Workflow style matches the structure of many business processes. Evolution by adding transformations is straightforward.  Disadvantages The format for data transfer has to be agreed between communicating transformations. It can not reuse architectural components that use incompatible data structures. 30  Chapter 6-5. Application architectures Application architectures [Application architectures]  Application systems used by the businesses have much in common.  Application architectures encapsulate the principal characteristics of a class of systems. Real-time system (e.g., data collection systems or monitoring systems)  Use case of application architecture models. As a starting point for architectural design process. As a design checklist. As a way of organizing the work of the development team. As a vocabulary for talking about application types. (Using the concepts identified in the generic architecture.) 31  Chapter 6-5. Application architectures Application architectures [The architectures of two types of application]  Transaction processing applications Database-centered applications that process user requests for information and update the information in a database. The most common types of interactive business systems. ex) Interactive banking systems, e-commerce systems, booking systems.  Language processing systems Systems in which the user’s intentions are expressed in a formal language, such as a programming language. Processing the language into an internal format and interpreting this internal representation ex) Compilers (high-level language programs → machine code). 32  Chapter 6-5. Application architectures Transaction processing systems [Transaction processing systems]  Processing user requests for information from a database, or requesting to update a database.  A transaction Any coherent sequence of operations that satisfies a goal. ex) “find the times of flights from Seoul to Pittsburgh :)” ex) “a customer request to withdraw money from a bank account using an ATM” 33  Chapter 6-5. Application architectures Transaction processing systems [The software architecture of an ATM system]  Transaction processing systems can be organized as a “pipe and filter architecture”, with system components. Two components: ATM software and the account processing software. 34  Chapter 6-5. Application architectures Information systems [About Information systems]  All systems that involve interaction with a shared database.  Web-based systems, where the user interface is implemented in a web browser.  The Information system is modeled using a layered approach. The top layer (e.g., user interface) The bottom layer (e.g., system database) 35  Chapter 6-5. Application architectures Information systems [The architecture of the Mentcare system] 36  Chapter 6-5. Application architectures Language processing systems [Language processing systems]  Translate one language into an alternative representation of that language.  Compiler Translate a program written in one language (“source language”) into a program written in another language (“target language”). Source code (e.g., C) Target code (e.g., x86) Compiler 37  Chapter 6-5. Application architectures Language processing systems [Front End of Modern Compilers]  The lexical analyzer transforms the character stream into a stream of tokens.  The syntax analyzer transforms the stream of tokens into a syntax tree.  The semantic analyzer checks if the program is semantically well-formed.  The IR translator translates the syntax tree into IR. 38  Chapter 6-5. Application architectures Language processing systems [Lexical Analyzer]  The lexical analyzer transforms the character stream pos = init + rate * 10 into a sequence of lexemes “pos”, “=”, “init”, “+”, “rate”, “*”, “10” and then produces a token sequence. (ID, pos), ASSIGN, (ID, init), PLUS, (ID, rate), MULT, (NUM,10) 39  Chapter 6-5. Application architectures Language processing systems [Syntax Analyzer]  The parser transforms the sequence of tokens (ID, pos), ASSIGN, (ID, init), PLUS, (ID, rate), MULT, (NUM,10) into the syntax tree: 40  Chapter 6-5. Application architectures Language processing systems [Semantic Analyzer]  ex) Type errors: int x = 1; string y = "hello"; int z = x + y;  Other semantic errors: array out of bounds null-dereference divide-by-zero 41  Chapter 6-5. Application architectures Language processing systems [IR Translator]  Intermediate Representation (IR): lower-level than the source language higher-level than the target language  ex) translate the syntax tree into three-address code: t1 = 10 t2 = rate * t1 t3 = init + t2 pos = t3 42  Chapter 6-5. Application architectures Language processing systems [A pipe and filter compiler architecture] 43 Chapter 6. Architectural design Summary Architectural patterns Application architectures 44