Software Architecture and Patterns 1 Outline Introduction Software

Software Architecture and Patterns 1

Outline � Introduction � Software Architecture and Architectural Design � Architectural Styles � System Structuring � Modular Decomposition � Control Styles � Pattern Categories � Architectural Patterns � Design Patterns � Idioms � Summary 2

Introduction What do we think an architecture is? The term architecture has been used for centuries to denote the physical structure of an artifact. 3

Introduction Architecture in Software Engineering �The software engineering community has adopted the term to denote the gross-level structure of software systems. �Due to the increasing complexity and the increasing size of the applications, the global structure of the software system became an important issue. 4

Introduction Definition of Software Architecture � "The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time. " [D. Garlan et al. , 1995] � "The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. " L. Bass, P. Clements & R. Kazman, Software Architecture in Practice, Addison Wesley 1998. 5

Introduction Architectural design �The design process for identifying the sub-systems making up a system and the framework for subsystem control and communication is architectural design. �Represents the link between specification and design processes. 6

Introduction Advantages of explicit architecture �Support stakeholder communication. �Enable parallel development. �Facilitate large-scale reuse. �Support several quality factors. 7

Introduction Packing robot control system 8

Architectural Styles What is an architectural style? �An architectural style is a pattern of system organisation such as client-server architecture or a layered architecture. �Styles constraints the component types and their patterns of interaction. 9

Architectural Styles Role of Architectural styles in Design �Knowledge about architectural styles can simplify the problem of defining system architectures. �For ex. , Client/Server is a common architectural style. �Different architectural models such as a structural model, a control model and a decomposition model may be developed. 10

Architectural Styles System structuring �Basic strategy that is used to structure a system. �Three styles are widely used: �A shared data repository style; �A shared services and servers style; �An abstract machine or layered style. 11

System Structuring The repository model �Suitable for sharing large amounts of data. �Shared data is held in a central database or repository and may be accessed by all sub-systems. 12

System Structuring CASE toolset architecture 13

System Structuring Repository model characteristics �Advantages �Efficient way to share large amounts of data; �Facilities for centralised management e. g. backup, security, etc. �Disadvantages �Sub-systems must agree on a repository data model. �Data evolution is difficult and expensive. 14

System Structuring Client-server model �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. 15

System Structuring Film and picture library 16

System Structuring Client-server characteristics �Advantages � Distribution of data is straightforward. � Makes effective use of networked systems. � Easy to add new servers. �Disadvantages � No shared data model so data interchange among subsytems may be difficult. � Separate management in each server. � No central register of names and services. 17

System Structuring Layered model �Organises the system into a set of layers each of which provide a set of services. �When a layer interface changes, only the adjacent layer is affected. �For ex: Layered communication protocols. �Structuring systems in a layered fashion is a difficult task. 18

System Structuring Version management system 19

Modular Decomposition Modular decomposition �Another structural level where sub-systems are decomposed into modules. �Two modular decomposition models covered � An object model where the system is decomposed into interacting object; � A pipeline or data-flow model where the system is decomposed into functional modules which transform inputs to outputs. 20

Modular Decomposition Object models Object Structure the system into a set of loosely coupled objects with welldefined interfaces. Object-oriented decomposition is concerned with identifying object classes, their attributes and operations. 21 Object

Modular Decomposition Invoice processing system 22

Modular Decomposition Object model advantages �Objects are loosely coupled so their implementation can be modified without affecting other objects. �The objects may reflect real-world entities. �OO implementation languages are widely used. 23

Modular Decomposition Function-oriented pipelining -1 Output Input data Transformation 1 Transformation 2 Transformation 3 Functional transformations process their inputs to produce outputs. Characterized as a series of transformations of input data. 24

Modular Decomposition Function-oriented pipelining -2 �Relatively simple to implement. �Requires a common format for data transfer along the pipeline. �Not suitable for interactive systems. 25

Modular Decomposition Invoice processing system 26

Control Styles Control styles �Are concerned with the control flow between subsystems. �Centralised control � One sub-system has overall responsibility for control and starts and stops other sub-systems. �Event-based control � Each sub-system can respond to externally generated events from other sub-systems or the system’s environment. 27

Control Styles Centralised control – Call&Return model Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. 28

Control Styles Centralised control - Manager Model One system component controls the stopping, starting and coordination of other system processes. 29

Control Styles Event-based control �Driven by externally generated events where the timing of the event is not controlled by the sub-systems that process the event. �Two principal event-driven models � Broadcast models. An event is broadcast to all sub-systems. � Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing. 30

Control Styles Broadcast model �Sub-systems register an interest in specific events. �Control is transferred to the sub-system which can handle the event. �Sub-systems decide on events of interest to them. 31

Control Styles Selective broadcasting 32

Control Styles Interrupt-driven model �Used in real-time systems where fast response to an event is essential. �There are known interrupt types with a handler defined for each type. �Each interrupt type is associated with a memory location. �Allows fast response but complex to program and difficult to validate. 33

Control Styles Interrupt-driven control 34

Patterns �The concept of patterns in software development has been derived from the writings of an architect Christopher Alexander. �A pattern is the abstraction of a problem in a specific domain and the representation of a generic solution to be used in different contexts. �Software patterns became popular with the book titled “Design Patterns: Elements of Reusable Object. Oriented Software” by Erich Gamma et al. 35

Patterns General Characteristics of Patterns -1 [Buschmann et al, 1996] �Patterns are heavily used in software architecture and design in the software community. �A pattern describes a solution to a recurring problem that arises in specific design situations. �Patterns are derived from well-proven design expertise. �Patterns describe a group of components (e. g. , classes or objects) and the interaction between the components. 36

Patterns General Characteristics of Patterns -2 [Buschmann et al, 1996] �Patterns are a means of documenting software architectures. �Patterns provide a conceptual skeleton for a solution to a design problem. �Patterns help designers manage the complexity of the software. �Patterns provide a vocabulary for communication among designers. 37

Patterns Pattern Categories � Patterns can be grouped according to their level of abstraction: 1. Architectural patterns 2. Design patterns 3. Idioms � Each category includes patterns that have a similar range of scale and abstraction. 38

Patterns Architectural patterns �An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. [Buschmann et al, 1996] �Examples of architectural patterns include; 1. Pipes and Filters pattern. 2. Layered systems. 3. Model-View-Controller(MVC). 39

Patterns Model-view controller -1 �An architectural pattern for GUI design. �MVC applications are splitted into three parts which comprises a relationship between a Model object, a View object and a Controller. 40

Patterns Model-view controller -2 �MVC pattern decouples changes to how data are manipulated from how they are displayed or stored. �Allows for multiple presentations of an object and separate interactions with these presentations. 41

Patterns Model-view-controller -3 42

Patterns Design patterns -1 �A design pattern provides a scheme for refining the subsystems of a software system, or the relationships between them. �A design pattern describes a commonly recurring structure of communicating components that solves a general design problem within a particular context. [Gamma et al. 1994] 43

Patterns Design patterns -2 �Medium-scale patterns. �The choice of a design pattern does not affect the fundamental structure of a software system but affects the structure of a subsystem. �Independent of the implementation language to be used. �They often rely on object characteristics such as inheritance and polymorphism. 44

Patterns Design patterns -3 �Gamma et al. , presents a catalog of design patterns organized according to their purpose: � Creational � Are related to the process of object orientation. � Structural � Deal with the composition of classes or objects. � Behavioral � Are related to the interaction between classes or objects. 45

Patterns Multiple displays 46

Patterns The Observer pattern � Name � Observer. � Description � Separates the display of object state from the object itself. � Problem description � Used when multiple displays of state are needed. � Solution description � Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. 47

Patterns The Observer pattern 48

Patterns Idioms �An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language. [Buschmann et al. , 1996] 49

Patterns Counted Body (Coplien, 1992) �An idiom for storage management of shared objects in C++. �The interface of a class is separated from its implementation. �Access to a shared object is controlled through two classes a Body (representation) class and a Handle (access) class. 50

Summary Software Architectures - summary � The software architecture is the fundamental framework for structuring the system. � Different architectural models such as a structural model, a control model and a decomposition model may be developed. � System structuring models include repository, client-server and abstract machine models. � Control models include centralised control and event-driven models. � Modular decomposition models include object models and pipelining models. 51

Summary Patterns � A pattern is the abstraction of a problem in a specific domain and the representation of a generic solution to be used in different contexts. � An architectural pattern expresses a fundamental structural organization schema for software systems. � Design patterns are high-level abstractions that document successful design solutions. � An idiom is a low-level pattern specific to a programming language. 52