1. Software Architecture and Patterns

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

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

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

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

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

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

8. Packing robot control system
Introduction
Packing robot control system

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

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

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

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

13. CASE toolset architecture
System Structuring
CASE toolset architecture

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

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

16. Film and picture library
System Structuring
Film and picture library

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

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

19. Version management system
System Structuring
Version management system

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

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

22. Invoice processing system
Modular Decomposition
Invoice processing system

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

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

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

26. Invoice processing system
Modular Decomposition
Invoice processing system

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

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

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

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

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

32. Selective broadcasting
Control Styles
Selective broadcasting

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

34. Interrupt-driven control
Control Styles
Interrupt-driven control

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

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

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

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

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

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

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

42. Model-view-controller -3
Patterns
Model-view-controller -3

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

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

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

46. Patterns
Multiple displays

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

48. Patterns
The Observer pattern

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

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

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

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