Software Engineering Architectural Design Chapter 6 Dr.Doaa Samy Modified from Sommerville’s originals

Objectives  Understand the importance of architectural design. 2  Understand the importance of architectural design.  Introduce to the architectural views.  Understand the decisions that be made during architectural design.  Know the architectural patterns that are often used in different types of application system.

Architecture 3  Architecture: Floor plan

Software Design The software design process is composed of four main 4 The software design process is composed of four main design activities:  Architectural design  this chapter.  Data design.  Component design.  Interface design.

Software Design Deliverables 5 The main deliverables of the Software Design are:  Software architecture.  Data structures.  Pseudo code.  Interface designs.  Software Design Document.

Software Engineering Architectural Design

UML diagram of system parts Software Engineering Architectural Design

Software Engineering Architectural Design

Software Engineering Architectural Design

Software Engineering Architectural Design

Software Engineering Architectural Design

Software Engineering Architectural Design

Example: Architectural design for “Packing robot control system” 20 Software Engineering Architectural Design

Software Architecture 6  Architectural Design: The design process concerned with understanding how a system should be organized and designing the overall structure of that system.  Software Architecture model: Output of this design process, describes how the system is organized as a set of communicating components.  A Software Architecture consists of:  Elements (components) with certain properties/behaviors.  Relationships between them.  Description of permitted and forbidden interactions.

Architectural Design 7  It is the first stage in the software design process.  It links between specification and design process.  Often carried out in parallel with some of the specification activities. However, this is not ideally.  It involves identifying main structural components in a system and the relationships between them.

Advantages of Explicit Architecture 8  Three advantages of explicitly designing and documenting software architecture: Stakeholder communication  Architecture is a high-level presentation. So, it may be used as a focus of discussion by different stakeholders. System analysis  Means that analyzing of whether the system can meet its critical non- functional requirements. Large-scale reuse  System architecture is often the same for systems with similar requirements and so can support large-scale software reuse.

Architectural Representations 9 UML was designed for describing object-oriented systems, it is not concerned with the design process. Object classes are too close to be useful for architectural description. Simple, informal block diagrams showing components and relationships are the most frequently used method. Boxes indicate to the components while arrows mean that data and or control signals are passed from component to another in the direction of the arrows.

Box and Line Diagrams 10  Block diagrams are an appropriate way of describing the system architecture during the design process.  Although they are very abstract, do not show the nature of relationships between components nor the components’ visible properties, they are useful for communication with stakeholders and for project planning.

Architectural Views 11  It is impossible to represent all relevant information about a system’s architecture in a single architectural model.  Each model only shows one view or perspective of the system such as: logical view, process view, development view, and physical view.  For both design and documentation, you usually need to present multiple views of the software architecture.

You don’t have to reinvent the wheel! Architectural Styles and Patterns 12  The architectural model of a system may conform to a generic architectural pattern or style.  Architectural Patterns/Styles capture the essence of an architecture that used in different software systems.  An awareness of these styles can simplify the problem of defining system architecture.  However, most large systems are heterogeneous and do not follow a single architectural style. You don’t have to reinvent the wheel!

Architecture and System Characteristics 13 A particular architectural style that you choose for a system should depend on the non-functional requirements (System Characteristics):  Performance  If it is critical, use large and few components  less communications.  Security  If it is critical, use a layered architecture with critical assets in the innermost layer with high level of validation in this layer.  Safety  If it is critical, put safety-critical features in one or small number of sub- systems to reduces costs in the event of failure.  Availability  If it is critical, include redundant components  update without stop.  Maintainability  If it is critical, use separate components and avoid shared data structure.

Architectural Design Decisions. 16  The software architect must make decisions about: System organization (structure) style. Decomposition style. Control style.  Evaluating different architectures for a software is sometimes refereed to as Tradeoff analysis.

1. System Organization system. 17  Reflects the basic strategy that is used to organize a system.  Three architectural styles are widely used:  An abstract machine or layered style;  A shared data repository style;  A client/server style.

Layered Architecture  Used to model the interfacing of sub-systems. 18  Used to model the interfacing of sub-systems.  Organizes the system into a set of layers (or abstract machines) each of which provide a set of services.  Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected.  Each layer provides a set of services to the layer above and serves as a client to the layer below.

Layered Architecture 19

Example: Abstract machine model for Version management system 30 Software Engineering Architectural Design

The Architecture of the LIBSYS System 20

Advantages & Disadvantages of Layered Style 21  Advantages:  Supports incremental development.  Changeable (if a layer changes, only adjacent layers are affected).  Disadvantages:  Structuring systems into layers is difficult.  Inner layers may provides facilities required by all layers (e.g. file management).  Performance is degraded.

Repository Style  Sub-systems must exchange data. 22  Sub-systems must exchange data.  This may be done in two ways: Shared data is held in a central database or repository and may be accessed by all sub-systems; 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.

Advantages & Disadvantages of Repository Style 23  Advantages:  Efficient way to share large amounts of data;  Sub-systems need not be concerned with how data is produced;  Centralized management e.g. backup, security, etc.  Sharing model is published as the repository schema.  Disadvantages:  Sub-systems must agree on a repository data model;  Data evolution is difficult and expensive;  No scope for specific management policies;  Difficult to distribute efficiently.

Repository Style for Project 24

Client-Server Architecture 25  Distributed system model which shows how data and processing is distributed across a range of components.  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 and server exchange data for processing.

 Advantages:  Disadvantages: Advantages & Disadvantages of Client–Server 26  Advantages:  Servers can be distributed across a network.  General functionality (e.g. printing service) can be available to all clients and does not need to be implemented by all services.  Easy add new server or upgrade existing one.  Disadvantages:  Security problem, each server will be suspected if a fault happen.  Performance may be unpredictable because it depends on the network as well as the system.  Management problems with servers owned by different organizations.

Client–Server Architecture for a Film Library 27

Object models decomposition Software Engineering Architectural Design

Example: Object models for Invoice processing system Software Engineering Architectural Design

Object models decomposition Advantages: Loose coupling ensures that changes in one object class does not affect other objects Since objects tend to reflect real-world entities, object models are easy to understand Disadvantages: Changes to the interface of an object have an impact on other users of the object Complex entities may be difficult to represent as objects Software Engineering Architectural Design

Decomposition Styles Not Really suitable to interactive systems. 28  We will cover one modular decomposition models  Pipe and filter or data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Not Really suitable to interactive systems.

Pipeline Model 29 Input Function Output 31

Pipe and Filter Architecture 30  Functional transformations process their inputs to produce outputs.  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.

Pipe and Filter 31

Invoice Processing System 32

 Advantages:  Disadvantages: The Pipe and Filter Pattern 33  Advantages:  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.  Disadvantages:  Not really suitable for interactive systems.  Although simple textual input and output can be modeled in this way, graphical user interfaces have more complex I/O formats which difficult to translated into a form compatible with the pipelining model.

Control models Refers to the control flow between sub-systems (not the same as system decomposition model) Centralized control One sub-system has overall responsibility for control and to start/shutdown other sub-systems Event-based control Each sub-system can respond to externally generated events; these events may come from other sub-systems or the system environment Software Engineering Architectural Design

Software Engineering Architectural Design

Centralised control One sub-system is responsible for managing the execution of other sub-systems. Depending on whether the controlled sub-system executes sequentially or in parallel, the centralized control models may be: Call-return model: Applicable to sequential systems. Control starts at the top of the hierarchy, and passes to lower level processes via function calls Manager model: Applicable to concurrent systems. Controlled by a designated manager system component that coordinates other processes Software Engineering Architectural Design

Centralized control: Call-return control model Software Engineering Architectural Design

Software Engineering Architectural Design

Centralized control: Manager control model Software Engineering Architectural Design

Example: Manager control model for Real-time system control 46 Software Engineering Architectural Design

Software Engineering Architectural Design

Event-driven systems: Broadcast model Software Engineering Architectural Design

Event-driven systems: Selective broadcasting Software Engineering Architectural Design

Event-driven systems: Interrupt-driven systems Software Engineering Architectural Design

Event-driven systems: Interrupt-driven control Software Engineering Architectural Design

The Architectures of Application 34  Application systems are intended to meet a business or organizational needs.  All businesses have much in in common—they need to hire people, issue invoices, keep accounts, and so on.  Commonalities led to development of software architectures that describe structure and organization of types of software systems.  The application architecture may be re-implemented when developing new systems, but many systems application reuse is possible without reimplementation.

The Architectures of Application 35  There are many types of application system and, in some cases, they may seem to be very different. Focus here is on two processing systems:  Transaction processing systems:  E-commerce systems.  Reservation systems.  Language processing systems:  Compilers.  Command interpreters.

Example 1: Transaction Processing Systems 36  Process user requests for information from a database or requests to update the database.  From a user perspective a transaction is:  Any 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.  All operations in a transaction have to be completed before the database changes are made permanent. This ensures that failure of operations within the transaction does not lead to inconsistencies in the database

Example 2: Language Processing Systems 37 Language processing systems are systems in which the user’s intentions are expressed in a formal language. The best-known example for these systems are compilers Compiler‘s components may implemented using different styles.

Summery 38  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 style 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.

Summary 39  Models of application systems architectures help us understand and compare applications, validate application system designs and assess large-scale components for reuse.  Transaction processing systems are interactive systems allow information in a database to be remotely accessed and modified by number of users.  Language processing systems are used to translate texts from one language into another and to carry out the instructions specified in the input language.