Architectural Patterns

Question 1

Definition

Answer 1

An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.

Question 2

Structural Patterns

Answer 2

• Layers
• Pipes and Filters
• Blackboard

Question 3

Distributed Systems Patterns

Answer 3

• Broker

Question 4

Interactive Systems Patterns

Answer 4

• Model-View-Controller
• Presentation-Abstraction-Control

Question 5

Adaptable Systems Patterns

Answer 5

• Microkernel
• Reflection

Question 6

Concurrent and Networked Objects Patterns

Answer 6

-

Question 7

Service Access and Configuration Patterns

Answer 7

• Wrapper Facade
• Component Configurator
• Interceptor
• Extension Interface

Question 8

Event Handling Patterns

Answer 8

• Reactor
• Proactor
• Asynchronous Completion Token
• Acceptor-Connector

Question 9

Synchronization Patterns

Answer 9

• Scoped Locking
• Strategized Locking
• Thread-Safe Interface
• Double-Checked Locking Optimization

Question 10

Concurrency Patterns

Answer 10

• Active Object
• Monitor Object
• Half-Sync/Half-Async
• Leader/Followers
• Thread-Specific Storage

Question 11

Structural AP

Answer 11

• From Mud to Structure
• Direct mapping Domain Model -> Architecture?
• Problems: non-functional qualities like portability, stability, maintainability, understandability…

Question 12

Layers

Answer 12

• Definition
  
  • The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.
• Example
  
  • Networking: OSI 7-Layer Model

Question 13

Layers addressed problems

Answer 13

• High-level and low-level operations
• High-level operations rely on low-level ones
  
  • ->Vertical structuring
• Several operations on the same level on abstraction but highly independent
  
  • ->Horizontal structuring

Question 14

Layers Forces

Answer 14

• Late source code changes should not ripple through the system.
• Interfaces should be stable and may even be prescribed by a standards body.
• Parts of the system should be exchangeable.
• It may be necessary to build other systems at a later date with the same low-level issues as the system you are currently designing.
• Similar responsibilities should be grouped to help understandability and maintainability.
• There is no ‘standard’ component granularity.
• Complex components need further decomposition.
• Crossing component boundaries may impede performance
• The system will be built by a team of programmers, and work has to be subdivided along clear boundaries.

Question 15

Layers rules

Answer 15

• Layer J uses ONLY services provided by Layer J-1
• Layer J provides services ONLY to Layer J+1
• BUT does NOT prescribe
  
  • The order to design the layers
  • The complexity of a layer