Software Architecture

Software Architecture

1. Client-server architecture

   • a. Include: Set of services and associated servers, Set of Clients, Network
   • b. Is 2-tier architectural style. (Tier: physical separation; Layer: logical separation)
   • c. Can be implemented on a single computer; but should be different processors.
   • d. Advantage: centralized system; keeps all the data and its controls in one place; high level of scalability, organization, and efficiency

2. N-tier Architecture

   • a. different layers of the system are separate processes that may execute on different processors.
   • b. additional servers are added to the system.

3. Peer-to-Peer Architecture

   • a. decentralized systems
   • b. computations can be carried out by any node on the network.
   • c. No clear distinction between clients and servers.
   • d. appropriate in two circumstances: i. Where the system is computationally intensive, and it is possible to separate the processing required into a large number of independent computations. ii. Where the system involves the exchange of information between individual computers on a network and there is no need for this information to be centrally stored or managed
   • e. Advantage: highly redundant; hence both fault-tolerant and tolerant of nodes disconnecting from the network
   • f. Disadvantage: security and trust; peers may behave in a malicious way

4. Blackboard/Shared Memory Architecture

   • a. “blackboard” is iteratively updated by a diverse group of specialist knowledge sources.
   • b. Each knowledge source updates the blackboard with a partial solution.
   • c. Incremental — complete solutions are constructed piece by piece and at a different level of abstraction.
   • d. Opportunistic — system chooses the actions to take next that will allow it to make the best progress.
   • e. Include: Blackboard (a structured global memory containing objects from the solution space); Knowledge sources (specialized modules with their own representation, for reading and writing on blackboard); Control component (selects, configures and executes modules).

5. Pipe and Filter Architecture

   • a. data-centric, structured around how data flows through the application.
   • b. Name comes from Unix.
   • c. In Linux: Piping is used to give the output of one command (written on LHS) as input to another command (written on RHS). Commands are piped together using vertical bar “|” symbol.
   • d. Advantage: Easy to understand and supports transformation reuse; Workflow style matches the structure of many business processes; Evolution by adding transformations is straightforward; Can be implemented as either a sequential or concurrent system.
   • e. Disadvantage: Format for data transfer has to be agreed; Each transformation must parse its input and unparse its output to the agreed form.

6. Layered Architecture

   • a. Organizes the system into layers with related functionality/logic associated with each layer.
   • b. each layer: Depends on the layers beneath it; independent of the layers on top of it; having no knowledge of the layers using it
   • c. Advantage: only need to understand the layers beneath the one we are working on; Each layer is replaceable; A layer can be used by several different higher-level layers.
   • d. Disadvantage: Layers cannot encapsulate everything; Coupling of code over time; Considerable amount of time to build/test/deploy.

7. Model-View-Controller (MVC) Pattern

   • a. Follows layered approach.
   • b. Separates presentation and interaction from the system data.
   • c. structured into three logical components that interact with one another: i. Model component: manages the system data and associated operations on the data. ii. View component: defines and manages how the data is presented to the user. iii. Controller component: manages user interaction (e.g., key presses, mouse clicks, etc.)

8. Model-View-View/Model (MVVM) Pattern

   • a. Derivative of the MVC architectural pattern.
   • b. model and view are not connected.
   • c. Business logic is decoupled from UI.
   • d. useful for developing applications with complex user interfaces or data-driven functionality.
   • e. recommended architecture patterns for developing Android applications.

9. Implicit Invocation/Event-Driven Architecture (EDA)

   • a. event producers: generate a stream of events.
   • b. event consumers: listen for the events.
   • c. instead of invoking a procedure directly, a component can announce (broadcast) one or more events. Other components register an interest in an event. When the event is announced, the system invokes all the interested procedures.
   • d. appropriate when multiple subsystems must process the same events and Real-time processing is needed with minimum time lag.