Download
1 / 51
510 likes | 695 Vues
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
E N D
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 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 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 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 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 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 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 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 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 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 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 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 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 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.
