1. 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

2. 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

3. 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

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

5. Object-Oriented

6. 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

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

8. 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

9. Virtual Machine

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

11. 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.

12. Client-Server

13. 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.

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

15. 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.

16. Batch-sequential

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

18. 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.

19. Pipe-and-Filter

20. 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.

21. 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.

22. 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.

23. Blackboard

24. 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.

25. 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.

26. Rule-Based/Expert System

27. 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.

28. 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

29. 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.

30. Basic Interpreter

31. 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

32. 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

33. Mobile Code

34. 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.

35. 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

36. 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.

37. Publish-Subscribe

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

39. 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.

40. Event Based

41. 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.

42. 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

43. Peer-to-Peer

44. 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.

45. 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

46. 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

47. 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.

48. C2

49. 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.

50. 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.

51. 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.