Lecture 5 Architectural Design & Patterns EPL603 Topics in Software Engineering Efi Papatheocharous Visiting Lecturer efi.papatheocharous@cs.ucy.ac.cy Office FST-B107, Tel. ext. 2740
Topics covered Software architecture Architectural design Architectural patterns Architectural patterns for distributed systems Lecture 5: Architectural Design & Patterns 2
Software architecture The architecture of a software system defines that system in terms of computational components and interactions among those components. [Shaw & Garlan, 1996] Architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. [IEEE 1471-2000] The software architecture of a system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements details having to do solely with internal implementation are not architectural. [Bass et al., 2003] Sources: IEEE Standard on the Recommended Practice for Architectural Descriptions, 2000. Shaw and Garlan, Software Architecture, Perspectives on an Emerging Discipline, Prentice-Hall, 1996 Bass, Clements, and Kazman, Software Architecture in Practice, SEI Series in Software Engineering. Addison-Wesley, 2003. Lecture 5: Architectural Design & Patterns 3
Importance of architecture The big problem according to David Garlan How to bridge the gap between requirements and solutions? Source: Keynote speech, The Changing Face of Software Architecture, CSEET, Carnegie-Mellon (March 2010), Available at: http://www.cs.cmu.edu/~garlan/external%20activities/cseet%20keynote.pdf Lecture 5: Architectural Design & Patterns 4
One possible answer The big problem according to David Garlan The process can be: Ad hoc Requires gurus Unpredictable Costly Source: Keynote speech, The Changing Face of Software Architecture, CSEET, Carnegie-Mellon (March 2010), Available at: http://www.cs.cmu.edu/~garlan/external%20activities/cseet%20keynote.pdf Lecture 5: Architectural Design & Patterns 5
The role of software architecture The big problem according to David Garlan High level system design System-level abstractions Architectural reuse design concepts Source: Keynote speech, The Changing Face of Software Architecture, CSEET, Carnegie-Mellon (March 2010), Available at: http://www.cs.cmu.edu/~garlan/external%20activities/cseet%20keynote.pdf Lecture 5: Architectural Design & Patterns 6
System design by decomposition Design by decomposition starts with a high-level description of the system s key elements. Then, iteratively refine the design by dividing each of the system s elements into its constituent pieces and describing their interfaces. The process is repeated until further refinement results in pieces that have no interfaces. Top level First level of decomposition Second level of decomposition Source: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010. Lecture 5: Architectural Design & Patterns 7
Example of various levels of architectures High-level architecture of the weather station Low-level architecture of Data Collection Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 8
Design models The software requirements model is transformed into design models that describe the details of the data structures, system architecture, interfaces, and components. Each design product is reviewed for quality before moving to the next phase of software development. Source: Pressman, R.S., Software Engineering: a Practitioner s Approach, 5th Rev. Ed., McGraw-Hill, 2000. Lecture 5: Architectural Design & Patterns 9
Architectural design In many ways, designing software resembles the process of designing a new house. There may not be a single best or correct architecture and the number of possible solutions may be limitless. By gleaning ideas from past solutions and by seeking regular feedback from the customer, designers can create good architecture, one that is able to accommodate and adapt to change, that will result to a product satisfying the customer and source of guidance throughout the products lifetime. Source: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010. Lecture 5: Architectural Design & Patterns 10
Architectural design Software design is a creative activity in which you identify software components and their relationships, based on customers requirements. Customers requirements generate a list of services that the customers requires from a system and include constraints under which it should operate. Software design is based on requirements and specification analysis. It will satisfy the functional and non-functional requirements of the system. Once interactions between the system and its environment have been understood, you use this information for designing the system architecture. Architectural design is the first stage in the software design process. Source: Lecture 5: Architectural Design & Patterns 11
Architectural design First you need to identify the major components that make up the system and their interactions, and then organize the components using possibly a suitable architectural pattern (such as a layered or client-server model). The activities within the process differs radically based on the type of system being developed, the background and experience of the system architect and specific system requirements. The process of realizing the design as a program (system implementation) the design may change, thus the implementation and the design activities are inter-leaved. Lecture 5: Architectural Design & Patterns 12
Architectural design decisions Is there a generic application architecture that can be act as a template? How will the system be distributed? What architectural patterns or styles are appropriate? What approach will be used to structure the system? How will the system be decomposed into modules (subcomponents)? Which architecture is best for delivering the non-functional requirements in the system? What control strategy for the components of the system should be used? How will the architectural design be evaluated? How should the architecture be documented? Lecture 5: Architectural Design & Patterns 13
Non-functional requirements and architectures (1/2) Non-functional req. Performance Security Safety Explanation If performance is a critical requirement the architecture should be designed to localize critical operations and minimize communication, with using a small number of components deployed on the same computer (rather than distributed). The components used should be relatively large, rather than small, fine-grained component. Also consider run-time system organization that allows the system to be replicated and executed on different processors to increase performance. If security is a critical requirement use a layered architecture with critical assets protected in the inner layers and a high level of validation applied to those layers. If safety is a critical requirement all safety-related operations should be either placed in a single component or in a small number of components. This reduces the costs and problems of safety validation and makes it possible to provide related protection systems that can safely shut down the system in the event of failure. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 14
Non-functional requirements and architectures (2/2) Non-functional req. Availability Maintainability Explanation If availability is a critical requirement the architecture should include redundant components, so that it is possible to replace and update components without stopping the system and should also include mechanisms for fault tolerance. However, this architecture potentially minimizes performance. If maintainability is a critical requirement the system architecture should include fine-grain, self-contained, replaceable components. Components producing data should be separated from components consuming data and shared data structures should be avoided. However, this architecture potentially minimizes performance. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 15
Architectural patterns We can improve our design by studying examples of good design. Thus, most design work is routine design, solve problem by reusing and adapting solutions from similar problems. [Pfleeger & Atlee] Architectural patterns were firstly introduced in the 90s under the name architectural styles (Shaw and Garlan, 1996) and other handbooks were published on pattern-oriented software architectures until 2007. Architectural patterns are stylized descriptions of good design practice, which have been tried and tested in different environments. They are a means of representing, sharing and reusing knowledge. They should include information about when they are and when the are not useful. They may be represented using tabular and graphical descriptions. Lecture 5: Architectural Design & Patterns 16
Need for architectural patterns Architectural patterns play the role of a blueprint (template) of a software system. Also, they play a critical role for the formation of the entire projects : Team structure Documentation organization Work Breakdown Structure (WBS) Planning, costing and budgeting Scheduling and resource allocation Control and organization of components Design and plan of implementation Integration and evolution Communication mechanisms Source: Shaw and Garlan, Software Architecture, Perspectives on an Emerging Discipline, Prentice-Hall, 1996 Lecture 5: Architectural Design & Patterns 17
Common architectural patterns (1/2) Architectural Style Client/Server* Component-Based Architecture Domain Driven Design Layered Architecture* Model View Controller (MVC)* Description Separates the system into two applications, where the client makes requests to the server. In many cases, the server is a database with application logic represented as stored procedures. Decomposes application design into reusable functional or logical components that expose well-defined communication interfaces. An object-oriented architectural style focused on modelling a business domain and defining business objects based on entities within the business domain. Partitions the concerns of the application into stacked groups (layers). Separates presentation and interaction from the system data. Lecture 5: Architectural Design & Patterns 18
Common architectural patterns (2/2) Architectural Style Message Bus N-Tier / 3-Tier* Object-Oriented Service-Oriented Architecture (SOA)* Repository* Description An architecture style that prescribes use of a software system that can receive and send messages using one or more communication channels, so that applications can interact without needing to know specific details about each other. Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer. A design paradigm based on division of responsibilities for an application or system into individual reusable and self-sufficient objects, each containing the data and the behaviour relevant to the object. Refers to applications that expose and consume functionality as a service using contracts and messages. The pattern where all data in a system is managed in a central repository that is accessible to all system components. Lecture 5: Architectural Design & Patterns 19
The pipe and filter architecture (1/3) In the pipe and filter architecture functional transformations process their inputs to produce outputs. May be referred to as a pipe and filter model (as in UNIX shell). Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems. Not really suitable for interactive systems. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 20
The pipe and filter pattern (2/3) Name Description When used Advantages Disadvantages Pipe and filter 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. Commonly used in data processing applications (both batch- and transaction-based) where inputs are processed in separate stages to generate related outputs. 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. 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. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 21
A pipe and filter example An example of a pipe and filter system used for processing invoices. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 22
The Model-View-Controller (MVC) pattern (1/3) Name Description When used Advantages Disadvantages MVC (Model-View-Controller) The Model-View-Controller pattern 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. Used: when there are multiple ways to view and interact with data; when the future requirements for interaction and presentation of data are unknown. 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. Can involve additional code and code complexity when the data model and interactions are simple. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 23
The Model-View-Controller (MVC) (2/3) Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 24
A Model-View-Controller (MVC) example The architecture of a web-based application system organized using the MVC pattern. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 25
The layered architecture (1/3) The layered architecture is used to model the interfacing of sub-systems. Organises the system into a set of layers (or abstract machines) each of which provide a set of services. Supports separation and independence between layers. Each layer relies only on the facilities and services offered by the layer immediately beneath it. Supports the incremental development in different layers of sub-systems, since ready services may be made available to users. When a layer interface changes, only the adjacent layer is affected. Thus, it localizes dependencies in the inner layers. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 26
The layered pattern (2/3) 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. When used Used : when building new facilities on top of existing systems; when the development is distributed (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. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 27
A layered architecture example (3/3) A layered model of a system for sharing copyright documents held in different libraries. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 28
The repository architecture (1/3) Sub-systems must exchange data. This may be done in two ways: Each sub-system maintains its own database and passes data explicitly to other sub-systems. Shared data is held in a central database or repository and may be accessed by all sub-systems; When large amounts of data are to be shared, the repository model of sharing is most commonly used a this is an efficient data sharing mechanism. Lecture 5: Architectural Design & Patterns 29
The repository pattern (2/3) Name Description When used Advantages Disadvantages Repository All data in a system is managed in a central repository that is accessible to all system components. Components do not interact directly, only through the repository. You should use this pattern when you have a system in which large volumes of information are generated that has to be stored for a long time. You may also use it in data-driven systems where the inclusion of data in the repository triggers an action or tool. Components can be independent they do not need to know of the existence of other components. Changes made by one component can be propagated to all components. All data can be managed consistently (e.g., backups done at the same time) as it is all in one place. 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. Lecture 5: Architectural Design & Patterns 30
A repository architecture example (3/3) A repository architecture model of an IDE The components use a repository of system design information. Each software tool generates information which is then available for use by other tools. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 31
The client-server architecture (1/3) The Client-Server (C/S) architecture is a distributed system model which shows how data and processing is distributed across a range of components. It can be implemented on a single computer. It depends on there being a clear separation between the presentation of information and the computations that create and process that information. In a client-server system The user can interact with a program running on their local computer (e.g. a web browser or phone-based application). This interacts with another program running on a remote computer (e.g. a web server). The remote computer provides services, such as access to web pages, which are available to external clients. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 32
The client-server pattern (2/3) Name Description When used Advantages Disadvantages Client-server 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. Used when data in a shared database has to be accessed from a range of locations. Because servers can be replicated, it may also be used when the load on a system is variable. 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. Each service is a single point of failure so susceptible to denial of service attacks (DoS 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. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 33
A client-server example (3/3) A film and video/dvd library organized as a client server system. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 34
Client server computing and interaction Distributed systems that are accessed over the Internet are normally organized as client-server systems. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 35
Mapping of clients and servers to networked computers Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 36
Layered client server computing Layered architectural model for client server applications May be structured into layers. With the presentation layer implemented on a client computer. Servers provide data management, application and db services. C S Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 37
The master-slave architecture (1/2) Master-slave architectures are commonly used in realtime systems where there may be separate processors associated with data acquisition from the system s environment, data processing and computation and actuator management. The master process is usually responsible for computation, coordination and communications and it controls the slave processes. Slave processes are dedicated to specific actions, such as the acquisition of data from an array of sensors. Lecture 5: Architectural Design & Patterns 38
A master-slave architecture example (2/2) A traffic management system example with master-slave architecture. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 39
Two-tier client server architectures (1/4) In a two-tier client-server architecture, the system is implemented as a single logical server (to centralize the system for security reasons) plus an indefinite number of clients that use that server. Thin-client model where the presentation layer is implemented on the client and all other layers (data management, application processing and database) are implemented on a server. Fat-client model where some or all of the application processing is carried out on the client. Data management and database functions are implemented on the server. Lecture 5: Architectural Design & Patterns 40
Thin- and fat-client architectural models (2/4) Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 41
Thin-client model (3/4) The thin-client model is used when legacy systems are migrated to client-server architectures. The legacy system acts as a server in its own right with a graphical interface implemented on a client. A major disadvantage is that it places a heavy processing load on both the server and the network. Lecture 5: Architectural Design & Patterns 42
Fat-client model (4/4) More processing is delegated to the client as the application processing is locally executed. Most suitable for new C/S systems where the capabilities of the client system are known in advance. Disadvantages include that it is more complex than a thinclient model especially for management and that new versions of the application have to be installed on all clients. An ATM system example with a fat-client architecture. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 43
Multi-tier client-server architectures (1/2) In a multi-tier client server architecture, there is a high volume of transactions to be processed by the server and there are different layers of the system. Namely the different layers are: Presentation, Data Management, Application Processing, and Database. They are separate processes that may be executed on different processors. This avoids problems with scalability and performance if a thinclient two-tier model is chosen, or problems of system management if a fat-client model is used. Lecture 5: Architectural Design & Patterns 44
A multi-tier client-server architecture example (2/2) A three-tier architecture for an internet banking system. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 45
Use of client server architectural patterns Architecture Two-tier C/S architecture with thin clients Two-tier C/S architecture with fat clients Multi-tier C/S architecture Applications Legacy system applications that are used when separating application processing and data management is impractical. Thus, the thin-clients may access these as services. Computationally intensive applications such as compilers with little or no data management. Data-intensive applications (browsing and querying) with nonintensive application processing. Browsing the Web is the most common example of a situation where this architecture is used. Applications where application processing is provided by COTS software (e.g., Microsoft Excel) on the client. Applications where computationally intensive processing of data (e.g., data visualization) is required on the client. Mobile applications where internet connectivity cannot be guaranteed. Some local processing using cached information from the database is therefore possible. Large-scale applications with hundreds or thousands of clients. Applications where both the data and the application are volatile. Applications where data from multiple sources are integrated. Lecture 5: Architectural Design & Patterns 46
Distributed component architectures (1/3) In distributed component architectures there is no distinction between clients and servers. Different systems and databases need to be combined. Each distributable entity is an object that provides services to other components and receives services from other components. Component communication is through a middleware system. However, distributed component architectures are more complex to design than C/S systems. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 47
Distributed component architectures (2/3) A distributed component architecture for a data mining system Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 48
Distributed component architectures (3/3) Distributed component architectures suffer from two major disadvantages: They are more complex to design than client server systems. Distributed component architectures are difficult for people to visualize and understand. There is not one standardized middleware for distributed component systems accepted by the community. Different vendors, such as Microsoft and Sun, have developed different, incompatible middleware. As a result of these problems, service-oriented architectures are replacing distributed component architectures in many situations. Lecture 5: Architectural Design & Patterns 49
Peer-to-peer (P2P) architectures (1/2) Peer to peer (P2P) systems are decentralised systems where computations may be carried out by any node in the network. They are used when clients exchange locally stored information to each other. The overall system is designed to take advantage of the computational power and storage of a large number of networked computers. Focus here on network architectures. Most P2P systems have been personal systems but there is increasing business use of this technology. The logical network architecture Decentralised architectures; Semi-centralised architectures. The application architecture The generic organization of components making up a P2P application. Lecture 5: Architectural Design & Patterns 50
P2P architectural models (2/2) Decentralised architectures Semi-centralised architectures Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 51
Software as a service Software as a Service (SaaS) involves hosting the software remotely and providing access to it over the Internet. Software is deployed on a server (or more commonly a number of servers) and is accessed through a web browser. It is not deployed on a local PC. The server(s) maintain the user s data and state during an interaction session. Transactions are usually long transactions e.g. editing a document. The software is owned and managed by a software provider, rather than the organizations using the software. Users may pay for the software according to the amount of use they make of it or through an annual or monthly subscription. Sometimes, the software is free for anyone to use but users must then agree to accept advertisements, which fund the software service. Lecture 5: Architectural Design & Patterns 52
SaaS and SOA Service-Oriented Architecture (SOA) is an approach to structuring a software system as a set of separate, stateless services. Factors These may be provided by multiple providers and may be distributed. Typically, transactions are short transactions where a service is called, does something then returns a result. Questions Configurability How do you configure the software for the specific requirements of each organization? Multi-tenancy Scalability How do you present each user of the software with the impression that they are working with their own copy of the system while, at the same time, making efficient use of system resources? How do you design the system so that it can be scaled to accommodate an unpredictably large number of users? Lecture 5: Architectural Design & Patterns 53
Configuration of a software system offered as a service Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Lecture 5: Architectural Design & Patterns 54
Configuration options Configuration facilities may allow for the following: Branding Users from each organization are presented with an interface that reflects their own organization. Business rules and workflows Each organization defines its own rules that govern the use of the service and its data. Database extensions Each organization defines how the generic service data model is extended to meet its specific needs. Access control Service customers create individual accounts for their staff and define the resources and functions that are accessible to each of their users. Lecture 5: Architectural Design & Patterns 55
Key points (1/2) A software architecture is a description of how a software system is organized. Architectural design decisions include decisions on the type of application, the distribution of the system, the architectural styles to be used. Architectural patterns are a means of reusing knowledge about generic system architectures. They describe the architecture, explain when it may be used and describe its advantages and disadvantages. Common architectural patterns include the pipe and filter pattern, Model-View-Controller (MVC) pattern, layered and repository patterns. Lecture 5: Architectural Design & Patterns 56
Key points (2/2) Architectural patterns for distributed systems include masterslave architectures, two-tier and multi-tier client-server architectures, distributed component architectures and peer-to-peer (P2P) architectures. Distributed component systems require middleware to handle component communications and to allow components to be added to and removed from the system. Peer-to-peer architectures are decentralized with no distinguished clients and servers. Computations can be distributed over many systems in different organizations. Software as a service is a way of deploying applications as thin client- server systems, where the client is a web browser. Lecture 5: Architectural Design & Patterns 57
Readings Chapters 6, 7 & 18 - Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010. Chapter 5 & Section 6.5 - Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010. Shaw and Garlan, Software Architecture, Perspectives on an Emerging Discipline, Prentice-Hall, 1996. Credits Slides adapted from Ian Sommerville Software Engineering, 9/E (http://www.cs.st-andrews.ac.uk/~ifs/books/se9/). Lecture 5: Architectural Design & Patterns 58