SIMPLE STYLES Traditional Language- influenced styles. Reflect the program styles that result from...

Post on 28-Dec-2015

220 views 0 download

transcript

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 programsCautions: 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 serversConnectors: Remote procedural calls, network

protocolsData 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:1. All components and connectors have to be

defined at the bottom2. Each component has a top and bottom

domain.3. Components may be hierarchically

composed.4. Each component may have its own control

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