Software Architecture Concepts

Component-and-Connector Structures

• Define the runtime behavior of systems using components (e.g., clients, servers) and connectors (e.g., call-return, pipes).
• Key questions addressed include:
  • Major executing components and their interactions.
  • Shared data stores and system replication.
  • Data flow and parallel execution potential.
  • Dynamic structure changes during execution.
• Important for evaluating runtime properties such as performance, security, and availability.

Allocation Structures

• Illustrate the relationship between software elements and their execution environments.
• Key queries include:
  • Processor assignments for software elements.
  • Storage locations during various stages (development, testing).
  • Team assignments for software elements.

Importance of Structures

• Structures provide analytical insights into software architecture and its quality attributes:
  • Module structure impacts system modifiability.
  • Concurrency structure is related to deadlock and performance management.
  • Deployment structure influences performance, availability, and security.

Useful Module Structures

• Decomposition Structure:
  • Modules are recursively decomposed into smaller units.
  • Facilitates understanding and localization of changes.
• Uses Structure:
  • Modules are related by dependency; one module using another requires the latter's correct functionality.
  • Supports incremental development and functionality extension.
• Layer Structure:
  • Composed of layers that act as virtual machines providing services through managed interfaces.

Useful Allocation Structures

• Deployment Structure:
  • Connects software elements to hardware and communication components.
  • Utilized for performance, data integrity, and security assessments in distributed systems.
• Implementation Structure:
  • Shows how software elements are organized in development and configuration environments.
• Work Assignment Structure:
  • Defines team responsibilities for implementation and integration of modules.

Relating Structures

• One structure's elements can relate to another structure’s elements, often performing many-to-many mappings (e.g., a module in decomposition may manifest as multiple components).

Architectural Patterns

• Architectural elements can be composed into established patterns that solve specific problems:
  • Common patterns include Shared-data and Client-server.
  • Promote reusable strategies that delineate the types and interactions of software elements.
• Common Patterns:
  • Multi-tier Pattern: Distributes system components across subsets of hardware/software.
  • Competence Center Pattern: Allocates work based on technical expertise.
  • Platform Pattern: Focuses on developing reusable assets for software product lines.

Characteristics of "Good" Architecture

• There's no definitive measure of good or bad architecture; effectiveness is context-dependent.
• Modifiability is enhanced when data changes are localized to production or consumption sides.

Structural Rules of Thumb

• Expect variation between modules and components; they are not one-to-one.
• Ensure processes can easily shift assignments across processors, potentially at runtime.
• Limit interaction patterns among components to reduce complexity and enhance reliability.
• Clearly specify resource contention areas within architecture.

Summary of Software Architecture

• Comprises structures essential for reasoning about the system, including software elements and their relationships.
• Three structure categories:
  • Module structures (code/data units).
  • Component-and-connector structures (runtime behavior and interactions).
  • Allocation structures (relations to external non-software elements).
• Structures are engineering leverage points; architectures vary in their suitability for particular purposes.