Software Architecture and Patterns

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

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

Architecture in Software Engineering 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.

Definition of Software Architecture 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.

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

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

Packing robot control system Introduction Packing robot control system

What is an architectural style? 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.

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.

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.

System Structuring Suitable for sharing large amounts of data. 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.

CASE toolset architecture System Structuring CASE toolset architecture

Repository model characteristics 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.

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.

Film and picture library System Structuring Film and picture library

Client-server characteristics 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.

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.

Version management system System Structuring Version management system

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.

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

Invoice processing system Modular Decomposition Invoice processing system

Object model advantages 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.

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

Function-oriented pipelining -2 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.

Invoice processing system Modular Decomposition Invoice processing system

Control Styles Control styles Are concerned with the control flow between sub-systems. 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.

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

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

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.

Control Styles Sub-systems register an interest in specific events. 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.

Selective broadcasting Control Styles Selective broadcasting

Interrupt-driven model 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.

Interrupt-driven control Control Styles Interrupt-driven control

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

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.

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.

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

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; Pipes and Filters pattern. Layered systems. Model-View-Controller(MVC).

Model-view controller -1 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.

Model-view controller -2 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.

Model-view-controller -3 Patterns Model-view-controller -3

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]

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.

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.

Patterns Multiple displays

Patterns The Observer pattern Name Description Problem 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.

Patterns The Observer pattern

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]

Counted Body (Coplien,1992) 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.

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.

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.