Traditional Language- influenced styles. SIMPLE STYLES Traditional Language- influenced styles. Reflect the program styles that result from traditional use of programming languages such as C, C++, Java and Pascal Discussed here are the architectures that primarily reflect basic organization and control-flow relationships between components

Main Program and Subroutines Decomposition based upon separation of functional steps Components: Main Program and subroutines Connectors: Functional/Procedural calls Data elements: Values passed in/out of subroutines

Main Program and Subroutines Typical use: Small programs Cautions: Typically fails to scale to large applications. Inadequate attention to data structures Unpredictable effort required to accommodate new requirements

Object-Oriented Objects must be instantiated before object methods are called Components: Objects Connector: Method invocation Data elements: Arguments to methods

Object-Oriented

Object-Oriented Typical use Applications involving complex dynamic data structures Applications where the designer wants a close relation between entities in the physical world and in the program Cautions: Relatively inefficient for high-performance applications with large numeric data structures like scientific computing Lack of additional structure principles can result into highly complex apps

LAYARED The essence of layered is the separation into ordered layers, wherein a program with one layer may obtain service from a layer below it The virtual machine style and the client-server layered style are ubiquitous in business apps and are discussed below

Virtual Machine Consists of an ordered sequence of layers where each layer offers a set of services that maybe accessed by programs. Components: Layers offer a set of services to other layers usually consisting of several programs Connectors: Procedural calls Data elements: Parameters passed between layers

Virtual Machine

Virtual Machine Typical Use: Operating system Cautions: Strict virtual machines with many levels can be relatively inefficient.

Client-Server Clients send service which request the server to perform the required functions and replies with the needed information. Components: Clients and servers Connectors: Remote procedural calls, network protocols Data elements: parameters and return values sent by connectors. Topology: Two-level, with multiple clients making requests to the server. Constraints: Client-to-client communication prohibited.

Client-Server

Client-Server Typical uses Applications with centralized data storage. Applications where clients perform simple user interface task such as most business apps. Cautions Limited bandwidth with a large number of client requests.

DATAFLOW STYLES Represented by: Batch-sequential. Pipe-and-Filter.

Batch-sequential Summary: Separate programs are executed in order. Data passed as an aggregate to the next. Components: Independent programs. Connectors: The human hand carrying tapes between programs, ”sneaker-net” Data-elements: Explicit, aggregate elements passed form one component to the next upon completion of execution. Topology: Linear Constraints: One program runs at a time.

Batch-sequential

Batch-sequential Typical uses Transaction processing in financial systems. Cautions When interaction between programs is a required. When concurrency between components is possible.

Pipe-and-Filter Summary: Separate programs are executed, potentially concurrently. Data is passed as a stream from one program to the next. Components: Independent programs known as filters. Connectors: Explicit routes of data streams. Data-elements: Not explicit; must be linear data streams. Topology: Pipeline, though T fittings are possible.

Pipe-and-Filter

Pipe-and-Filter Typical uses Ubiquitous in operating system application programming. Cautions When complex data structures must be exchanged between filters. Interactivity between programs is required.

SHARED STAE/MEMORY Multiple components have access to the same the data store and communicate through that data store. The use of global data in programming is usually one of several means to communicate between programs. These systems include: Blackboard Rule-Based/Expert System.

Blackboard Summary: Independent programs access and communicate exclusively through a global data repository known as a blackboard. Components: Independent programs. Connectors: Access to blackboard may be by direct memory reference, or can be through a procedure call or database. Data-elements: Data stored in the blackboard Topology: Star topology, with the blackboard at center.

Blackboard

Blackboard Typical uses Heuristic problem solving in artificial intelligence application. Cautions When a well-structured solution strategy is available. When interactions between the independent programs require complex regulation.

Rule-Based/Expert System Summary: Inference engine parses user input and determines whether it is a fact or query. If it is a fact, it adds this entry to the knowledge base. Components: User interface, inference engine, knowledge base. Connectors: Components are tightly interconnected, with direct procedure calls or shared data access. Data-elements: facts and queries. Topology: Tight coupled three-tier.

Rule-Based/Expert System

Rule-Based/Expert System Typical uses: When the problem can be be understood as matter of repeatedly resolving a set of predicates. Cautions: When a large number of the rules involved. Understanding the interactions between multiple rules affected by the same facts can become very difficult.

INTERPRETER The distinctive characteristic of interpreter is dynamic on-the –fly interpretation of commands. Commands are phrased in terms of predefined primitive commands. Interpretation proceeds by starting with an initial execution state, obtaining the first command to execute, executing the command over the current execution state, therefore modifying the state before going on to the next. Such styles include: Basic Interpreter Mobile code

Basic Interpreter Summary: Interpreter and executes input commands, updating the state maintained by the interpreter. Components: Command interpreter, program/Interpreter state, user interface. Connectors: Typically the command interpreter, user interface, and state are very closely bound with direct procedure calls and shared state. Data-elements: Commands Topology: Tightly coupled three-tier.

Basic Interpreter

Basic Interpreter Typical uses: Superb for end-user programmability Supports dynamically change of capabilities. Cautions: When fast processing is needed. Memory management may be an issue

Mobile Code Summary: Code moves to be interpreted on another host; depending on the variant, state does also. Components: Execution dock, which handles receipt and deployment of code and state. Connectors: Network protocols and elements for packing code and data for transmission. Date-elements: Representation of code as data. Topology: Network

Mobile Code

Mobile Code Typical uses: When processing large data sets in distributed locations, it becomes more efficient to have the code move to the location of these large data sets. Cautions: Security issues-execution of imported code may expose the host machine to mal-ware.

IMPLICIT INVOCATION The two styles below are characterized by calls that are invoked indirectly and implicitly as a response to a notification or an event. These styles are: Publish-Subscribe Event-Based

Publish-Subscribe Summary: Subscribers register/deregister to receive specific messages or specific content. Publishers maintain a subscription list and broadcast message to subscribers synchronously Components: Publishers, subscribers, proxies for managing distributions. Connectors: Procedure calls may be used with in programs. Data-elements: Subscription, notifications, published information. Topology: Subscribers connect to publishers either directly or may receive info via a network protocol.

Publish-Subscribe

Publish-Subscribe Typical uses: News dissemination Multiplayer-network-based games Cautions: When the number of subscribers for a single data item is very .

Event Based Summary: Independent components asynchronously emit and receive events communicated over event buses. Components: Independent, concurrent event generators and/or consumers. Connectors: Event bus. In variants, more than one may be used. Data-elements: Events Topology: Components communicate with the event-buses not directly to each other.

Event Based

Event Based Typical uses: User interface software Wide area applications involving independent parties. Cautions. No guarantee if or when a particular event will be processed.

Peer-to-Peer Summary: State and behavior are distributed among peers that can act as either clients or servers. Components: Peers-independent components having their own state and control thread. Connectors: Network protocols, often custom. Data elements: Network messages. Topology: Network

Peer-to-Peer

Peer-to-Peer Typical uses: Where source of information and operations are distributed and network is ad hoc. Cautions: Security-P2P must make provisions for detecting malicious peers. When information retrieval is time critical and cannot afford latency imposed by the protocol.

MORE COMPLEX STYLES These are more complex than the designs discussed above and have arisen from efforts to exploit design knowledge from substantial experience. The complexity reflects a provision of greater benefits and and specialization to certain contexts. These include: C2 Distributed Objects

C2 Summary: An indirect invocation style in which independent components communicate exclusively through message routing connectors. Strict rules on connections between components and connectors induce layers Components: Independent, potentially concurrent message generators or consumers. Connectors: Message routers that may filter, translate and broadcast messages of 2 kinds; notification and requests. Data-elements: Messages. Request messages request performance of an action. Topology: Layers of components and connectors

C2 Constraints: All components and connectors have to be defined at the bottom Each component has a top and bottom domain. Components may be hierarchically composed. Each component may have its own control threads. There can be no assumption of a shared address space among components.

C2

C2 Typical uses: Reactive, heterogeneous applications. Applications demanding low-cost adaptability Cautions: Event routing across multiple layers can be inefficient. Overhead high for some simple kinds of component interaction.

Distributed Objects Summary: Applications functionally broken down into objects that can run on heterogeneous hosts and can be written in heterogeneous programming languages. Objects invoke methods across host, process and language boundaries via remote procedural calls. Components: Objects. Connector: remote procedural calls. Data-elements: Arguments to methods, return values and exceptions. Topology: General graph of objects from callers to callees.

Distributed Objects Typical uses Creation of distributed software systems composed of components running on different hosts. Integration of software components written in different programming languages. Cautions: Difficulty in dealing with high streams of data flow. Interactions tend to be mostly synchronous and don’t take advantage of concurrency present in distributed systems.