Typical architectural styles

Prepared by Mrs. M Praveena,HOD MCA

objectives
To learn various software architectural styles; To learn how different software architectural styles are interrelated.

DATA FLOW
Data flow is a software architectural style that is widely used in various application domains where data processing plays a significant role. There are three different type styles in this
1. The general data-flow style 2. The pipe and filter sub-style 3. The batch sequential processing sub style

The pipe-and-filter architectural style is a special case of data flow style.

The general data flow style

A. B. C. D. E. F. Computational model Design vocabulary Structural pattern Essential invariants Sub-types of the style Properties derived from the architecture

The general data flow style

Computational model:
The computational model of an architectural style is the overall mechanism that a system in the style works. The data flow style is characterized by viewing the system as a series of transformations on successive pieces of input data. Data enter the system and then flow through the components one at a time until they are assigned to some final destination (output or data store).

The general data flow style

Design vocabulary:
Associated to each architectural style is a set of design vocabulary about the specific types of components and connectors that can be used in the systems of the style, the particular design considerations often concerned the designers of such a system, and so on.

The general data flow style

The general data flow style

Essential invariants:
Systems of a style may be different from each other on a number of features. One of the essential invariants for data flow systems is that there is no interaction between processing elements other than data flows. Moreover, each processing element must be on a path from the input to an output.

The general data flow style

Sub-types of the style:
A way of understanding what can be different for systems in a style is to recognize its sub-styles. There are two main subtypes of data flow style, batch sequential processing and pipe-and-filter.

The general data flow style

Properties derived from the architecture: In the data flow architecture, components are highly independent. There is no global control of the components' behaviour. The processing elements can be executed concurrently, even on different computers. They are capable of processing continuous streams of data, which may be theoretically without a limit on the length of input data, and provide continuous control and monitoring functions of real-time process control systems.

The general data flow style

A possible difficulty in the design and implementation of a data flow architecture is the synchronization of the computations of more than one processing element, if such synchronizations are necessary.

The general data flow style

Example:
Many web-based applications can be regarded as in the data flow architectural style. The client side executes on the user's computer and is connected to the web-server through the inteernet. The web server processes sequences of user's requests, which is in the form of messages, and passes the requests to a database server for processing database queries.

The general data flow style

The pipe-and-filter sub-style

A. B. C. D. E. Computational model Design vocabulary Structural pattern Properties derived from the architecture Sub-types of the style

The pipe-and-filter sub-style

Computational model:
The pipe-and-filter architectural style is a sub-type of data flow style. Therefore, the computational model of data flow is also the model for pipes-and-filters style. Each component in a software system of pipe-and-filter style incrementally reads in streams of data on its inputs and incrementally produces streams of data on its outputs. The outputs from one component are directly fed to another component as its inputs. The connectors of this style serve as conduits for the streams, transmitting outputs of one filter to another filter's input.

The pipe-and-filter sub-style

Design vocabulary:
The components in a pipes-and-filters architecture are called filters. The connectors in pipe-and-filter systems are called

pipes.
There are three important constraints on the components and the connectors of pipe and-filter architecture. Those are 1. Independence 2. Anonymity. 3. Concurrency

The pipe-and-filter sub-style

Independence:
Filters must be independent entities. In particular, they should not share state with each other.

Anonymity:
Filters do not know the identity of their upstream and downstream filters. Their specifications might restrict what appears on the input pipes or make guarantees about what appears on the output pipes

Concurrency.
The correctness of the output of a pipe-and-filter network should not depend on the order in which the filters perform their incremental processing- although fair scheduling can be assumed.

The pipe-and-filter sub-style

Structural pattern:
There is no structure restriction in addition to that of the restrictions of data flow architectural style.

The pipe-and-filter sub-style

Properties derived from the architecture:
Pipe-and-filter systems have a number of nice properties. Those are They allow the designer to understand the overall input/output behaviour of a system as a simple composition They support reuse systems are easy to maintain and enhance data are incrementally processed they naturally support concurrent execution

The pipe-and-filter sub-style

However, these systems also have their disadvantages. Those are pipe-and-filtersystems often lead to a batch organisation of processing They may be hampered by having to maintain correspondence between two separate but related streams. Depending on the implementation, they may force a lowest common denominator on data transmission, resulting in added work for each filter to parse and un parse its data.

The pipe-and-filter sub-style

Sub-types of the style:
The main sub-type of this style is pipeline. Pipeline architectures are pipes-and filters systems in which there is no cycle of data flows.

The batch sequential processing substyle

A. B. C. D. Computational model Design vocabulary Structural pattern Properties derived from the architecture

The batch sequential processing substyle

Computational model:
Batch sequential processing is also a sub-type of data flow architectural style. In the batch sequential style, components are independent programs. They are executed sequentially, i.e. one component runs to completion before the next starts. The data is transmitted between components as a whole batch rather than a stream of data elements.

The batch sequential processing substyle

Design vocabulary:
The computational components in a batch sequential processing architecture are often called processing steps or phases.

Structural pattern:
Batch sequential processing architectures usually consist of a finite number of steps linearly connected. some batch sequential processing systems contain loops that repeat some processing steps for a finite number of times.

The pipe-and-filter sub-style

Properties derived from the architecture:
Batch sequential processing architectures inherit almost all advantages of the data flow architectural style, especially the reusability and modifiability. It avoids complicated issues related to the synchronization between components by executing them one after another. It usually cannot deal with continuous streams of inputs with unbounded lengths.

The batch sequential processing substyle

Examples:
A transaction processing system that illustrates batch sequential processing style, where data passed from one step to another is stored on tapes.

INDEPENDENT COMPONENTS
The architectural style of independent components has attracted increasing interest recently for its strong support to software reuse and evolution due to its ease of integration of components into a system. It has a number of sub-types of style including communicating processes, event-based implicit invocation and multi agent systems.

The general independent components style

A. B. C. D. E. F. Computational model Design vocabulary Structural pattern Essential invariants Sub-types of the style Properties derived from the architecture

The general independent components style

Computational model:
Independent component architecture consists of a number of components that communicate through messages. They send data to each other but typically do not directly control each other.

Design vocabulary:
All components of a system in the independent component style must be executable. They are often called processes if the component is active. Otherwise, they are often just called modules.

The general independent components style

Structural pattern:
There is no general pattern of system structure for the whole class of independent component architectural style with regard to the topological structures of the systems.

Essential invariants:
The essential invariant of all sub-types of the independent component style is that the only means of information exchange among the components is message passing.

The general independent components style

Properties derived from the architecture:
Independent component architectures achieve modifiability by decoupling various portions of the computation. It enables concurrent executions of the components, even parallel executions of components on various computers over a network. advantage of decoupling computation into independent components is that it eases component integration.

The general independent components style

Sub-types of the style:
There are a number of sub-types of independent component architectural styles including the communicating process systems and the eventbased implicit invocation systems

The general independent components style

Example:
A typical example of independent component architecture is the client-server architecture A client-server system usually consists of a number of clients and one or more servers

The general independent components style

A client component sends messages to a server to request the execution of a certain Computational task to be performed by the server. Upon receiving such a request, the server decides whether to perform the requested task, and if it decides to do so, the outcome or the result of the task is fed back to the client by sending a message. There are numerous concrete examples of such client-server systems in web-based applications.

The event based implicit invocation systems sub-style

Event-based systems are a sub-type of independent component architectures in which control is part of the model. A. Computational model B. Design vocabulary C. Structural pattern D. Properties derived from the architecture

The event based implicit invocation systems sub-style

Computational model :
Individual components in an event-based implicit invocation system announce data that they wish to share with their environment- a set of unnamed components.

Design vocabulary:
A component's announcement of data is usually called publishing the data. Such an announcement is also called an event. A component's registration of its interests in certain data is called subscription. A message manager in an event-based implicit invocation system is also often called event handler.

 Structural pattern:

The event based implicit invocation systems sub-style

The interface of a component in event-based implicit invocation systems usually contains a collection of events that it can raise and a collection of procedures or functions that other components can call directly.

The event based implicit invocation systems sub-style

Properties derived from the architecture:
As a sub-type of independent components architectural style, event-based implicit invocation style inherits all the advantages and disadvantages of independent components architectures

The communicating processes sub-style

Another sub-type of independent component architectures is the architectural style of communicating processes. A. Computational model B. Design vocabulary C. Structural pattern D. Sub-types of the style

The communicating processes sub-style

Computational model:
The components of a system in the communicating processes style are active processes. They pass messages to each other to synchronizes their executions and to achieve mutual exclusion in accessing shared resources.

Design vocabulary:
The components in a communicating processes system are called processes and they communicate with each other through communication channels and ports, where messages are sent and received.

The communicating processes sub-style

Structural pattern:
The general structure of communicating processes systems is a network of processes connected by communication channels. The messages passed between processes usually contain requests of performing certain tasks rather than just the data to be processed.

Sub-types of the style:

Client-server architecture is a well-known sub-type of communicating processes.

CALL and RETURN

Call-and-return architecture has been the dominant architectural style in large systems for the past 30 years. There are three different styles 1. The general call and return style 2. The layered systems sub-style 3. Data abstraction: the abstract data type and object-oriented substyles

The general call and return style

Computational model Structural pattern Design vocabulary Properties derived from the architecture Sub-types of the style

The general call and return style

Computational model:
A software system in call and return style is essentially decomposed into smaller pieces to deal with complexity and to help achieve modifiability. There is typically a single thread of control. Each component executes only when it gets this control from another component and returns the control to that component when it terminates execution.

The general call and return style

Each component usually has a fixed entry where the executions of the components start. A component also has some fixed locations called exits where executions terminate. Such components are called subroutines. The passes of control from one component to another are called subroutine calls or invocations, which are often combined with passing data as the parameters. The component that has the entrance to the whole program is usually called the main program. This is supported by all high level languages

The general call and return style

Structural pattern: system in the call and return style can have any topological structure that links subroutines by subroutine calls.

The general call and return style

Design vocabulary: A common practice in the design of a call and return system is to organize subroutines into a hierarchy. A call and return architecture with a hierarchical structure is often called the mainprogram-and-subroutine with shared data . In fact, this can be considered as a sub-type of the call and return style. In a call and return system, a group of subroutines that share a common data store can be grouped together to form a module.

The general call and return style

A basic rule that guides the grouping of subroutines into modules is loose coupling and high cohesion . High cohesion means that the subroutines within onemodule should have intensive interconnection in terms of the number of calls between the subroutines and, perhaps more importantly, the frequency that one subroutine calls another at run-time. Loose coupling means that there are few interconnections across the boundary of modules in terms of both statically the links between the subroutines of different modules and dynamically the frequency of subroutine calls across module boundary at run-time.