SET212 Software Engineering 2 Lecture 5 PDF

Software Engineering 2 SET212 1 Lecture #5 Dr./ Ahmed Osman Mahmoud  Lecture #5 2 Architectural Design Dr./ Ahmed Osman Mahmoud 3 References  Software Engineering 10th Edition by Ian Sommerville (Chapter 6) 4 Objective understand why the architectural...

Software Engineering 2 SET212 1 Lecture #5 Dr./ Ahmed Osman Mahmoud  Lecture #5 2 Architectural Design Dr./ Ahmed Osman Mahmoud 3 References  Software Engineering 10th Edition by Ian Sommerville (Chapter 6) 4 Objective understand why the architectural design of software is important. understand the decisions that have to be made about the software architecture during the architectural design process have been introduced to the idea of Architectural patterns, well-tried ways of organizing software architectures that can be reused in system designs 5 Architectural Design 6 Architectural Design Architectural design is concerned with understanding how a software system should be organized and designing the overall structure of that system. In the model of the software development process, architectural design is the first stage in the software design process. It is the critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them. 7 Architectural Design The output of the architectural design process is an architectural model that describes how the system is organized as a set of communicating components. To help you understand what is system architecture, look at Figure This diagram shows an abstract model of the architecture for a packing robot system. 8 9 Architectural Design This robotic system can pack different kinds of objects. It uses a vision component to pick out objects on a conveyor, identify the type of object, and select the right kind of packaging. 10 Architectural Design The system then moves objects from the delivery conveyor to be packaged. It places packaged objects on another conveyor. The architectural model shows these components and the links between them. 11 Architectural Design In practice, there is a significant overlap between the processes of requirements engineering and architectural design. Ideally, a system specification should not include any design information. You need to identify the main architectural components as these reflect the high-level features of the system. 12 Architectural Design Therefore, as part of the requirements engineering process, you might propose an abstract system architecture where you associate groups of system functions or features with large-scale components or subsystems. 13 Architectural Design You can design software architectures at two levels of 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 may be distributed over different computers, which may be owned and managed by different companies. 14 Architectural Design Software architecture is important because it affects the performance, robustness, distriputability, and maintainability of a system. Designing and documenting software architecture has three advantages: 1. Stakeholder communication 2. System analysis 3. Large-scale reuse 15 Architectural Design Decisions 16 Architectural Design Decisions Architectural design is a creative process in which you design a system organization that will satisfy the functional and non-functional requirements of a system. There is no formulaic architectural design process. It depends on the type of system being developed, the background and experience of the system architect, and the specific requirements for the system. The best consideration to consider architectural design as a series of decisions to be made rather than a sequence of activities.  Architectural design decisions – common questions (though a creative process) 17 Is there a generic application architecture that can be used? How will the system be distributed? What architectural styles are appropriate? What approach will be used to structure the system? How will the system be decomposed into modules? What control strategy should be used? How will the architectural design be evaluated? How should the architecture be documented? 18 19 Architectural Design Decisions Although each software system is unique, systems in the same application domain often have similar architectures that reflect the fundamental concepts of the domain. For example, application product lines are applications that are built around a core architecture with variants that satisfy specific customer requirements. When designing a system architecture, you have to decide what your system and broader application classes have in common, and decide how much knowledge from these application architectures you can reuse. 20 Architectural Design Decisions The architecture of a software system may be based on a particular Architectural pattern or style (these terms have come to mean the same thing).  An Architectural pattern is a description of a system organization, such as a client–server organization or a layered architecture. 21 Architectural Design Decisions requirements Performance: If performance is very important, the system should be designed to focus critical operations in a few components, all on the same computer instead of spreading them across the network. This means using larger components rather than smaller ones, as this reduces the need for communication between them. You can also consider setups that allow the system to run on multiple processors to enhance performance. 22 Architectural Design Decisions requirements Security: If security is a critical requirement, a layered structure for the architecture should be used, with the most critical assets protected in the innermost layers and a high level of security validation applied to these layers. Safety: If safety is a critical requirement, the architecture should be designed so that safety-related operations are co-located in a single component or in a small number of components. This reduces the costs and problems of safety validation and may make it possible to provide related protection systems that can safely shut down the system in the event of failure. 23 Architectural Design Decisions requirements Availability: If availability is a critical requirement, the architecture should be designed to include redundant components so that it is possible to replace and update components without stopping the system. fault-tolerant system architectures for high-availability systems. Maintainability: If maintainability is a critical requirement, the system architecture should be designed using fine- grain, self-contained components that may readily be changed. Producers of data should be separated from consumers, and shared data structures should be avoided. 24 Architectural Views 25 Architectural views It is impossible to represent all relevant information about a system’s architecture in a single diagram, as a graphical model can only show one view or perspective of the system. There are four fundamental architectural views. 26 27 Architectural views 1. A logical view, which shows the key abstractions in the system as objects or object classes. It should be possible to relate the system requirements to entities in this logical view. 2. A process view, which shows how, at runtime, the system is composed of interacting processes. This view is useful for making judgments about non-functional system characteristics such as performance and availability. 28 Architectural views 3. A development view, which shows how the software is decomposed for development; that is, it shows the breakdown of the software into components that are implemented by a single developer or development team. This view is useful for software managers and programmers. 4. A physical view, which shows the system hardware and how software components are distributed across the processors in the system. This view is useful for systems engineers planning a system deployment. 29 Architectural patterns 30 Architectural patterns The idea of patterns as a way of presenting, sharing, and reusing knowledge about software systems has been adopted in a number of areas of software engineering. An Architectural pattern as a stylized, abstract description of good practice, which has been tried and tested in different systems and environments. An Architectural pattern should describe a system organization that has been successful in previous systems. It should include information on when it is and is not appropriate to use that pattern, and details on the pattern’s strengths and weaknesses. Patterns may be described in a standard way using a mixture of narrative description and diagrams.  31 Architectural patterns Figure describes the well-known Model- View-Controller pattern.  This pattern is the basis of interaction management in many web-based systems and is supported by most language frameworks  32 Architectural patterns Graphical models of the architecture associated with the MVC pattern. These present the architecture from different views: Figure 6.5 is a conceptual view,  33 Architectural patterns Figure 6.6 shows a runtime system architecture when this pattern is used for interaction management in a web- based system. 34 Layered Architecture 35 Layered Architecture The system functionality is organized into separate layers, and each layer only relies on the facilities and services offered by the layer immediately beneath it. layered approach supports the incremental development of systems. As a layer is developed, some of the services provided by that layer may be made available to users. The architecture is also changeable and portable. 36 Layered Architecture If its interface is unchanged, a new layer with extended functionality can replace an existing layer without changing other parts of the system. when layer interfaces change or new facilities are added to a layer, only the adjacent layer is affected. As layered systems localize machine dependencies, this makes it easier to provide multi-platform implementations of an application system.  37 Layered Architecture pattern This pattern is shown in Figure 6.7. Here, the system functionality is organized into separate layers, and each layer only relies on the facilities and services offered by the layer immediately beneath it.  38 Layered Architecture  Figure 6.8 is an example of a layered architecture with four layers.  The lowest layer includes system support software— typically, database and operating system support.  The next layer is the application layer, which includes the components concerned with the application functionality and utility components used by other application components.  The third layer is concerned with user interface management and providing user authentication and authorization,  with the top layer providing user interface facilities.  Of course, the number of layers is arbitrary. 39 Repository Architecture 40 Repository Architecture Sub-systems must exchange data. This may be done in two ways: 1. Shared data is held in a central database or repository and may be accessed by all sub-systems; 2. Each sub-system maintains its own database and passes data explicitly to other 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  41 Repository Architecture pattern the Repository pattern describes how a set of interacting components can share data..  42 Repository architecture for an IDE  Figure illustrates a situation in which a repository might be used.  This diagram shows an IDE that includes different tools to support model- driven development.  the repository is passive, and control is the responsibility of the components using the repository. 43 Repository Architecture The majority of systems that use large amounts of data are organized around a shared database or repository. This model is therefore suited to applications in which data is generated by one component and used by another.  Examples of this type of system include command and control systems, management information systems, Computer-Aided Design (CAD) systems, and interactive development environments for software. 44 Client–server Architecture 45 Client–server Architecture The Repository pattern is concerned with the static structure of a system and does not show its runtime organization. A system that follows the Client–Server pattern is organized as a set of services and associated servers, and clients that access and use the services. 46 Client–server Architecture The major components of Client–server Architecture model are: 1. A set of servers that offer services to other components. Examples of servers include print servers that offer printing services, file servers that offer file management services, and a compile server that offers programming language compilation services. Servers are software components, and several servers may run on the same computer. 2. A set of clients that call on the services offered by servers. There will normally be several instances of a client program executing concurrently on different computers. 3. A network that allows the clients to access these services. Client– server systems are usually implemented as distributed systems, connected using Internet protocols.  47 Client–server Architecture pattern the Client–Server pattern (Figure 6.12), illustrates a commonly used runtime organization for distributed system.  48 A client–server architecture for a film library  Figure 6.13 is an example of a system that is based on the client–server model.  This is a multiuser, web- based system for providing a film and photograph library.  In this system, several servers manage and display the different types of media. 49 Pipe and filter architecture 50 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. 51 Pipe and filter pattern 52 A client–server architecture for a film library 53 Pipe and filter architecture Pipe and filter systems are best suited to batch processing systems and embedded systems where there is limited user interaction. Interactive systems are difficult to write using the pipe and filter model because of the need for a stream of data to be processed. While simple textual input and output can be modeled in this way, Graphical user interfaces have more complex I/O formats and a control strategy that is based on events such as mouse clicks or menu selections. It is difficult to implement this as a sequential stream that conforms to the pipe and filter model. 54