GoV Patterns for Software Architecture-Patterns in Software Engineering-Lecture 7 Slides-Computer Engineering, Slides of Software Engineering

Download GoV Patterns for Software Architecture-Patterns in Software Engineering-Lecture 7 Slides-Computer Engineering and more Slides Software Engineering in PDF only on Docsity!

Patterns inSoftware EngineeringSoftware Engineering Lecturer: Raman RamsinLecturer:

Raman Ramsin

Lecture 7 GoV Patterns – Architectural

P^ t 1

Department of Computer Engineering

1

Sharif University of Technology

Part 1

Patterns in Software Engineering – Lecture 7 GoV Patterns for Software Architecture^ A^ di

t^ B

h^

t^ l

„^ According to Buschmann et al.:^

^ A

pattern for software architecture describes a particular recurringp^

p^

g

design problem that arises in specific design contexts, andpresents a well-proven generic scheme for its solution.

The solution scheme is specified by describing^ „^ the constituent components^ „^ The responsibilities and relationships of the components„^ The responsibilities and relationships of the components^ „^ the ways in which the components collaborate.

Department of Computer Engineering

2

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 GoV Patterns: Pattern Schema „ Context:

Design situation giving rise to a design problemg^

g^ g^

g^ p

„^ Problem:

Set of forces (requirements, constraints, and

d^ i^ bl

i^ )^

dl^ i i

i^ h

h

desirable properties) repeatedly arising in the context thatneed to be addressed „ Solution:

Configuration to balance the forces

^ Structure with components and relationships ^ Structure with components and relationships ^ Run-time

behavior

Department of Computer Engineering

3

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 GoV Patterns: Categories „ Architectural^

^ Expresses a fundamental structural organization schema for software ^ Expresses

a fundamental structural organization schema for software

systems.^ „^ Provides a set of predefined subsystems (or components), specifies theirresponsibilities, and includes rules and guidelines for organizing thel ti^

hi^ b t^

th relationships between them.

„^ Design^

^ Provides a scheme for refining the subsystems or components of asoftware system

or the relationships between them

software system, or the relationships between them.^ „^ Describes a commonly-recurring structure of communicating components thatsolves a general design problem within a particular context. „ Idiom „ Idiom

Low-level pattern specific to a programming language.^ „^ Describes how to implement particular aspects of components or therelationships between them using the features of the given language.

Department of Computer Engineering

4

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 Architectural Patterns: Categories „ From Mud to Structure^

^ Support a controlled decomposition of a system task into cooperating subtasks.pp

p^

y^

p^ g

^ Layers,

Pipes and Filters, and

Blackboard

„^ Distributed Systems^

^ Deal with the infrastructure of distributed applications ^ Deal

with the infrastructure of distributed applications. Broker; alsoMicrokernel and

Pipes and Filters, which only consider distribution as a

secondary concern. „ Interactive Systems „ Interactive^

Systems

^ Support the structuring of systems that feature human-computer interaction. ^ Model-View-Controller and

Presentation-Abstraction-Control

Ad^ t^ bl

S^ t

„^ Adaptable Systems^

^ Support extension of applications and their adaptation to evolving technology andchanging functional requirements.^ ^ Reflection and

Microkernel Department of Computer Engineering

5

Sharif University of Technology

^ Reflection

and^ Microkernel

Patterns in Software Engineering – Lecture 7 Architectural: From Mud to Structure „ Layers:

Helps to structure applications that can be decomposed into

groups of subtasks.g^ p^

^ Each group of subtasks is at a particular level of abstraction. „ Pipes and Filters:

Provides a structure for systems that process a

„^ Pipes

and Filters:

Provides

a structure for systems that process a

stream of data.^

^ Each processing step is encapsulated in a filter component.^ ^ Data is passed through pipes between adjacent filters. ^ Data is passed through pipes between adjacent filters.^ ^ Recombining filters allows you to build families of related systems. „ Blackboard:

Useful for problems for which no deterministic solution

„^ Blackboard:

Useful for problems for which no deterministic solution

strategies are known.^

^ Several specialized subsystems assemble their knowledge to build apossibly partial or approximate solution.Department of Computer Engineering

6

Sharif University of Technology

possibly^ partial or approximate solution.

Patterns in Software Engineering – Lecture 7 From Mud to Structure: Layers „ Helps to structure applications that can be decomposed into groupsof subtasks in which each group of subtasks is at a particular level ofof subtasks in which each group of subtasks is at a particular level ofabstraction. Department of Computer Engineering

7

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 From Mud to Structure: Layers „ Context -

A large system that requires decomposition.

„^ Problem -

Forces are as follows:

^ Late source code changes should not ripple through the system.

g^

pp^

g^ y

^ Interfaces should be stable. ^ Parts of the system should be exchangeable. ^ It may be necessary to build other systems at a later date with the same low-levelissues as the system you are currently designingissues as the system you are currently designing. ^ Similar responsibilities should be grouped to help understandability andmaintainability. ^ There is no 'standard' component granularity. ^ Complex components need further decomposition. ^ Crossing component boundaries may impede performance. ^ The system will be built by a team of programmers, and work has to be subdividedalong clear boundariesDepartment of Computer Engineering

8

Sharif University of Technology

along^ clear boundaries.

Patterns in Software Engineering – Lecture 7 Layers: Structure Department of Computer Engineering

9

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 Layers: Dynamics „ Scenario I:

Top-down communication initiated by a client.

„^ Scenario II:

Bottom-up communication, when a chain of actions

starts at Layer 1; for example when a device driver detects input. „ Scenarios III and IV:

Requests only travel through a subset of the

layers.^

^ III: A top level request may only go to level N 1 lf this level can satisfy ^ III: A top-level request may only go to level N-1 lf this level can satisfythe request; e.g. when level N-1 acts as a cache.^ ^ IV: A bottom-level request may only travel through the next few upper-level layers.e e^

aye s

„^ Scenario V:

involves two stacks of N layers communicating with

each otherDepartment of Computer Engineering

10

Sharif University of Technology

each^ other.

Patterns in Software Engineering – Lecture 7 Layers: Consequences 9 Reuse of layers 9 Support for standardization 9 Dependencies are kept local 9 Exchangeability

d^ f^

h^

b h

8 Cascades of changing behavior 8 Lower efficiency 8 Potential for unnecessary work 8 Difficulty of establishing the correct granularity of layersDepartment of Computer Engineering

11

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 From Mud to Structure: Pipes and Filters „ Provides a structure for systems that process a stream of data. Eachprocessing step is encapsulated in a filter component. Data is passedprocessing step is encapsulated in a filter component. Data is passedthrough pipes between adjacent filters. Department of Computer Engineering

12

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 From Mud to Structure: Pipes and Filters „ Context -

Processing data streams.

„^ Problem -

Forces are as follows:

^ Future system enhancements should be possible by exchanging processingsteps or by recombination of steps, even by users. ^ Small processing steps are easier to reuse in different contexts than largeones. ^ Non adjacent processing steps do not share information ^ Non-adjacent processing steps do not share information. ^ Different sources of input data exist. ^ It should be possible to present or store final results in various ways. ^ Explicit storage of intermediate results for further processing in files clutters ^ Explicit storage of intermediate results for further processing in files cluttersdirectories and is error-prone, if done by users. ^ You may not want to rule out multi-processing the steps, for example runningthem in parallel.Department of Computer Engineering

13

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 Pipes and Filters: Structure Department of Computer Engineering

14

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 Pipes and Filters: Structure

• Filters and Pipes

„^ Filter:

processing unit of the pipeline. ‰ Enriches ,^ refines

or^ transforms

its input data.

‰^ Its activity can be triggered by several events:‰^ Its activity can be triggered by several events:^ „^ subsequent pipeline element pulls output data from the filter (

passive ).

„^ The previous pipeline element pushes new input data to the filter (

passive ).

„^ Most commonly, the filter is

active^ in a loop. y,^

p

„^ Pipe:

connection between filters. ‰ If two active components are joined, the pipe synchronizes them. Thissynchronization is done with a first-in- first-out buffer.y

Department of Computer Engineering

15

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 Pipes and Filters: Structure

• Sources and Sinks

„^ The^ data source

represents the input to the system, and provides af d t l^

f th^

t^ t^

t

sequence of data values of the same structure or type.^ ‰^ Examples of such data sources are a file consisting of lines of text, or asensor delivering a sequence of numbers.Th^ d t^

i k^ ll^

t^ th^

lt^ f^

th^ d^

f th^ i^

li

„^ The^ d

ata sink^

collects the results from the end of the pipeline.

Department of Computer Engineering

16

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 Pipes and Filters: Dynamics – Scenario I „ Push pipeline in which activity starts with the data source. Filteractivity is triggered by writing data to the passive filters. Department of Computer Engineering

17

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 Pipes and Filters: Dynamics – Scenario II „ Pull pipeline in which the control flow is started by the datasink calling for data. Department of Computer Engineering

18

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 Pipes and Filters: Dynamics – Scenario III „ mixed push-pull pipeline with passive data source and sink.

p^ p^

p p^

p

Department of Computer Engineering

19

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 Pipes and Filters: Dynamics – Scenario IV „ All filters actively pull, compute. and push data in a loop.

y p^ ,^

p^

p^

p

Department of Computer Engineering

20

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 Pipes and Filters: Consequences 9 No intermediate files necessary, but possible 9 Flexibility by filter exchange and recombination 9 Reuse of filter components 9 Rapid prototyping of pipelines 9 Efficiency by parallel processing 8 Sharing state information is expensive or inflexible 8 Efficiency gain by parallel processing is often an illusion 8 Efficiency gain by parallel processing is often an illusion 8 Data transformation overhead 8 Error handling is difficultDepartment of Computer Engineering

21

Sharif University of Technology

8 Error

handling is difficult

Patterns in Software Engineering – Lecture 7 Architectural: Distributed Systems „ Broker:

Used to structure distributed software systems with

decoupled components that interact by remote service invocations.p^

p^

y

^ Abroker component is responsible for coordinating communication, such asforwarding requests, as well as for transmitting results and exceptions. „ Microkernel:

Separates a minimal functional core

(microkernel)

from extended functionality and customer-specific parts.^

^ Applies to software systems that must be able to adapt to changing systemrequirementsrequirements.^ ^ Microkernel systems employ a Client-Server architecture in which clients andservers run on top of the microkernel component. „ Pipes and Filters:

Provides a structure (possibly distributed) for

systems that process a stream of data.Department of Computer Engineering

22

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 Distributed Systems: Broker „ Used to structure distributed software systems with decoupledcomponents that interact by remote service invocations.Ab^

k^

t i^

ibl^ f^

di^ ti^

i^ ti^

h

^ A^ broker component is responsible for coordinating communication, suchas forwarding requests, as well as for transmitting results and exceptions. Department of Computer Engineering

23

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 Distributed Systems: Broker „ Context

-^ Your environment is a distributed and possibly

„^ Context

Your^ environment is a distributed and possibly

heterogeneous system with independent cooperating components. „ Problem -

Forces are as follows:

^ Components should be able to access services provided by othersthrough remote

location-transparent service invocations

through remote, location-transparent service invocations.

You need to exchange, add, or remove components at run-time. The architecture should hide system- and implementation-specific detailsfrom the users of components and services.from the users of components and services.

Department of Computer Engineering

24

Sharif University of Technology

Patterns in Software Engineering – Lecture 7 Broker: Structure

• Brokers and Bridges

„^ Brokers

are messengers that are responsible for the transmission of

requests from clients to servers and requests from clients to servers, and responses and exceptions back to the client.

„^ Bridges

are optional components used for hiding implementationdetails when two brokers interoperatedetails when two brokers interoperate.

Department of Computer Engineering

25

Sharif University of Technology