Architectual Pattern

Recurring architectual design problem
- Architectural design solution
  - components
  - connections
    - Topology: connectivity: if A,B connects in Design
    - Static vs. Dynamic

Layered Architectures - Architectural pattern

Problem
- Levels of abstraction
- flexibility to reconfigure / port
Soltuion:
- Components: Layers
  - each layer represents a level of abstraction
- Connectivity:
  - topology
    - DAG (Directed Acyclic Graph) / Tree / Linear
      - dependency directions : from higher-level layer to lower-level layer
        
        A layer can depend only on the layer below it
  - connections
    - function calls, data format (e.g. streams), distributed calls, executable language
- Consequence:
  - benefit:
    - Flexibility (layer reconfiguration: layers can be replaced)
    - Improved understandability of the system
  - drawbacks:
    - have to standardize to smallest common denominator
    - runtime performance cost

Pure Form of Layer Architecture

Only Adjacent Layers Communicate

Cross-Layer Optimization (Relaxed form of Layered Architecture)

Look at the L-shaped Layer! thats the signature

A compromise to address the two drawbacks

Note the topology of this architecture is a DAG.

Consequence:

benefit:
- can take advantage of special Hareware feature
  - Providing access to special features
- can optimize away middle layer call cost for performance critical functionality
  - Improving performance
drawbacks:
- Reduced modifiability (and portability)

Dependency Inversion

We mentioned that dependency directions : from higher-level layer to lower-level layer

To solve the problem
- Use Callback Interface

Example:

Another example:

Step1: Move the classes to the left

Step2: Make a interface

Step3: connect classes function to the interface

Tiered Architectures - Architectural pattern

Multi Tier systems

Layered architectures
- Layers are physical processes, often distributed
  - Now Layers become tiers
  - types: frontend/UI, services, DB layer

Why:

Scalability
UI, business logic, data
- Evolve at different speeds
- required different skills

Two-Tier Architecture (old, people use Multi Tier systems instead now):

Client and Server tier
- Client : UI + Business Logic
- Server : Data + Business Logic

Why do we need Tiered Architectures?

There is a code smell: Divergent Change

Divergent Change : each part of the code evolve in different speeds
Since UI, Business Logic, and Data evolve in different speeds
- so we use Tiered Architecture

Implicit Invocation - Architectural pattern

Rather than using direct procedure / function call
- use publish-subscribe mechanism (implict invocation, call back, events)
  - one method to implement implicit invocation is the Observer pattern
Publish subscribe architecture
- Components
  - Publish information, sometimes divided into topics
    - Subscribe to topics, to receive updates

Benefit
- don’t need to all subscribers in advance
- Reconfigurable at runtime by adding and removing subscribers
Cons
- don’t reply on the order calling subscribers
- added complexity

Observer Pattern

Intent: define one-to-many dependency between objects so that if one object changes state, all its dependents are notified

Model View Controller (MVC)

Model => Subject with state (Background Logic)
Controller => operations that change the state (UI Logic)
View => show on the screen (UI)

Note that View is invoked through Implicit Invocation (the indriect calls)!

Model uses Implicit Invocation to update views whenever it changes

Practice Questions

1: Consider the following UML class diagram representing a layered system.

1a: What constraint of the layered architecture style does this design violate?

dependency directions only allow from high-level to lower-level.

1b: What refactoring can you apply to eliminate this violation?

Dependency Inversion!

1c: Please draw the resulting design after applying the refactoring?

Step1: Move the InBox to the left

Step2: Make a interface

Step3: connect InBox function to the interface

2: Consider the following specifications of application logic and classify it as business or UI control logic.

2a: Customer should not be able to withdraw money if the account balance less than or equal zero.

Business Logic
2b: Pushing the save button will open a transaction and save the current customer and update the customer list on the screen.

UI control logic
2c: The withdraw button should be disabled when the customer is not allowed to withdraw money.

UI control logic

3: Why it is a good idea to separate UI control logic, business logic, and data base access code?

Scalability. Since UI control logic, business logic, and database access code evolve at different speeds.

Each of them evolves at different speed in response to different forces (e.g., UI control logic depends on usability and UI technology (mobile vs. desktop); business logic evolves as business rules change; data base evolves as the data model changes and as the data base schema is optimized).

4: What are the two key advantages of using the layered architecture pattern?

Improved understandability of the system

Flexibility (layer reconfiguration: layers can be replaced)

1. Improved understandability of the system by allowing higher level functionality to be expressed in terms of lower-level functionality

2. Improved modifiability, esp. portability, as layers can be replaced

5: Consider the layered architecture below:

5a: What is the topology of this architecture (stack, tree, or DAG)?

DAG

5b: Note the L-shaped Hardware layer. What is the technical term for this arrangement?

Cross-layer optimization

5c: Note the L-shaped Hardware layer. What is the main reason to use this arrangement?

improve performance;
provide access to special features

5d: Note the L-shaped Hardware layer. What is the main disadvantage of this arrangement?

reduced modifiability

6: How a view is typically invoked in MVC?

By Implicit Invocation from the model

7: Consider the following system:

development environment capable of integrating a set of tools (e.g., compiler, editor, debugger, etc.) produced by different vendors; as an example of such interaction, stepping through a program in the debugger should automatically position the editor on the source line being executed;

7a: Which architectural pattern is most appropriate for the given system?

Notice the keyword here: interaction, automatically

Publish-subscribe (or implicit invocation)

7b: Sketch the resulting architectural view.

7c: Give the reason for selecting a given pattern for the given system. List possible disadvantages (if any) for the given choice.

The publish-subscribe style allows plugging together independently developed components as long as there is some agreement on the type of events published and consumed. For example, stepping through the debugger can generate the event step; the editor can subscribe to this event and position the source code correctly after receiving each step event.

The main disadvantage of publish subscribe architectures is that they are difficult to debug.

8: Consider the following system:

Online-banking web application with graphical user interface, business logic, and data base.

8a: Which architectural pattern is most appropriate for the given system?

Notice the keyword here: UI, Business Logic and Database!

Tiered Architecture (3-layer )

8b: Sketch the resulting architectural view.

8c: Give the reason for selecting a given pattern for the given system. List possible disadvantages (if any) for the given choice.

Online banking is a typical example of an enterprise application with GUI, business logic, and DB. These three components should be separated since they usually evolve at different speeds.

The basic three-tier architecture does not support application integration well. Service layer, publish-subscribe facility, messaging, and REST help address this shortcoming.