architecture

Lecture 5 – Architectural Design & Patterns

EPL603 – Topics in Software Engineering Efi Papatheocharous Visiting Lecturer [email protected] 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.


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


4

One possible answer


The process can be:

 Ad hoc  Requires gurus  Unpredictable

 Costly



5

The role of software architecture


 High level system design  System-level abstractions  Architectural reuse design concepts



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.


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.


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:


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.


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?


13

Non-functional requirements and architectures (1/2) Non-functional req.

Explanation

Performance

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.

Security

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.

Safety

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.

Explanation

Availability

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.

Maintainability

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.


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

Description

Client/Server*

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.

Component-Based Architecture

Decomposes application design into reusable functional or logical components that expose well-defined communication interfaces.

Domain Driven Design

An object-oriented architectural style focused on modelling a business domain and defining business objects based on entities within the business domain.

Layered Architecture*

Partitions the concerns of the application into stacked groups (layers).

Model View Controller (MVC)*

Separates presentation and interaction from the system data.


18

Common architectural patterns (2/2) Architectural Style

Description

Message Bus

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.

N-Tier / 3-Tier*

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.

Object-Oriented

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.

Service-Oriented Architecture (SOA)*

Refers to applications that expose and consume functionality as a service using contracts and messages.

Repository*

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.


20

The pipe and filter pattern (2/3) Name

Pipe and filter

Description

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.

When used

Advantages

Disadvantages


21

A pipe and filter example

 An example of a pipe and filter system used for processing invoices.


22

The Model-View-Controller (MVC) pattern (1/3) Name

MVC (Model-View-Controller)

Description

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.

When used

Advantages

Disadvantages


23

The Model-View-Controller (MVC) (2/3)


24

A Model-View-Controller (MVC) example

 The architecture of a web-based application system organized using the MVC pattern.


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. 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. 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. 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.

When used

Advantages

Disadvantages


27

A layered architecture example (3/3)

 A layered model of a system for sharing copyright documents held in different libraries.


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.


29

The repository pattern (2/3) Name

Repository

Description

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.

When used

Advantages

Disadvantages


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.


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

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. 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.

When used

Advantages

Disadvantages


33

A client-server example (3/3)

 A film and video/DVD library organized as a client–server system.


34

Client–server computing and interaction

 Distributed systems that are accessed over the Internet are normally organized as client-server systems.


35

Mapping of clients and servers to networked computers


36

Layered client–server computing  Layered architectural model for client–server applications C

 May be structured into layers.  With the presentation layer implemented on a client computer.

S

 Servers provide data management, application and db services. 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.


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)


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.


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.


44

A multi-tier client-server architecture example (2/2)

 A three-tier architecture for an internet banking system.


45

Use of client–server architectural patterns Architecture

Applications

Two-tier C/S architecture with thin clients

• 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.

Two-tier C/S • Applications where application processing is provided by COTS architecture software (e.g., Microsoft Excel) on the client. with fat clients • 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. Multi-tier C/S architecture

• Large-scale applications with hundreds or thousands of clients. • Applications where both the data and the application are volatile. 5: Architectural Design & Patterns • ApplicationsLecture where data from multiple sources are integrated.

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.


47

Distributed component architectures (2/3)

 A distributed component architecture for a data mining system


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.


50

P2P architectural models (2/2)

Decentralised architectures

Semi-centralised architectures


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.  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. Factors

Questions

Configurability

• How do you configure the software for the specific requirements of each organization?

Multi-tenancy

• 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?

Scalability

• How do you design the system so that it can be scaled to accommodate an unpredictably large number of users?


53

Configuration of a software system offered as a service


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.


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.


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/).


58

architecture

architecture

Suggest Documents

Architecture

Architecture

Architecture

Architecture

Architecture Arcanum Architecture, San Francisco ...

Architecture Classical Architecture Rococo ...

Architecture Architecture docx.pdf - Google Drive

Enterprise Architecture & Security Architecture Development

software architecture: architecture constraints - Lirmm

Architecture Arcanum Architecture, San Francisco ...

Landscape Architecture Magazine Features ... - 360 Architecture

Service Oriented Architecture Reference Architecture

TriCore Architecture Volume1: Core Architecture V1.3 ... - Infineon

The Choice Architecture of Choice Architecture

CSE 502: Computer Architecture - Computer Architecture Stony ...

Discover Architecture - School of Architecture - Oklahoma State ...

Discover Architecture - School of Architecture - Oklahoma State ...

An architecture for autonomic security adaptationUne Architecture ...

Modern Architecture - UCD School of Architecture, Planning ...

Architecture, Culture & Spirituality (ACS) - Architecture, Culture ...

ART & ARCHITECTURE TRAIL GUIDE - Kielder Art & Architecture

An Architecture for Toolbox-based Software Architecture ...

OpenIDM Architecture

Computer architecture