Software Architecture: Design and Decisions

• Software architecture is a set of documented structures resulting from design decisions driven by architectural drivers.
• Design decisions are made by the architect while considering requirements and constraints.

Purpose of Software Architecture

• Communicates design to stakeholders at project start.
• Enables early analysis of high-level design, updating later is costly.
• Identifies opportunities for large-scale component reuse at the project's inception.
• Detailed documentation at project end makes the system easier to understand and evolve.

Key Architectural Decisions

• Determine if a generic architecture applies to the project.
• Decide how the system will be distributed.
• Determine the decomposition of the system into modules.
• Define how components interact with each other.
• Establish how the design will be evaluated and documented.

Robotic Package Sorter Example

• A robot uses a camera to detect objects on a conveyor belt.
• The robot identifies the object type.
• The robot selects appropriate packaging for the object.
• The robot places the object on the correct conveyor for packaging.
• This system serves as a case study for exploring architectural decisions and tradeoffs.

Quality Attributes and Architectural Decisions

• Critical operations should be localized and communication minimized for performance.
• Self-contained components promote maintainability, such as a modular robot control system.
• Layered architecture with critical components in inner layers enhances security, like protecting sorter control logic.
• Minimizing critical components improves safety, like ensuring the sorter stops if packaging fails.
• Introducing redundancy increases availability, such as backup servers for sorter control.

Architectural Tradeoffs

• Large-grain components improve performance due to fewer interactions.
• Fine-grain components enhance maintainability through easier updates.
• Separating arm and grip controllers in the sorter is a tradeoff example.
• Redundancy increases availability but may compromise security if not managed well.
• Localizing safety features improves safety but may reduce performance.

Architectural Styles

• Generic templates created by design experts simplify defining system architectures.
• Large systems often blend multiple styles rather than adhering to one.

Pipe and Filter Style

• Data flows through a sequence of processing steps.

Blackboard Style

• Components collaborate via a shared data structure.

Client-Server Architecture

• Clients request services from servers over the internet.
• Easy service distribution.
• Enables effective use of networked systems.
• Simple to add/upgrade servers.
• Has redundant server management.
• Lacks a shared data model and central service registry.
• Presents single points of failure.
• Has unpredictable performance.
• Can face management issues across organizations.

Layered Style

• Offers increasing abstraction levels.
• Changes affect only adjacent layers.
• Allows different implementations if interfaces are preserved.
• May introduce performance overhead due to layering,
• Not all systems fit this model.
• Determining abstraction levels can be complex.

Model-View-Controller (MVC)

• Separates data (Model), presentation (View), and logic (Controller).
• In a music player app, the Model (song data) updates the View (UI) via the Controller (user inputs).
• Adding external speakers to the app requires the Controller to manage external speaker output.
• The Model may need new audio routing logic.
• The View updates to reflect speaker status.
• Compatibility with speaker protocols and latency in audio routing pose challenges.
• Maintaining UI responsiveness is important.

Design Patterns

• General concepts (not specific code) from design experts address common challenges, ensuring clean and maintainable code.
• Design patterns adapt software to changing requirements with minimal component changes.
• Design patterns are higher-level than algorithms and are reusable strategies.

Object Creational Patterns

• Enhance flexibility and reuse in object creation.

Singleton Pattern

• Ensures a class has only one instance with global access.
• A single database connection shared across a program is a use case.
• AccountNumberGenerator ensures one instance generates unique account numbers.

Structural Patterns

• Assemble objects/classes into flexible, efficient structures.

Decorator Pattern

• Dynamically adds responsibilities to objects without modifying their code.
• Adding features (e.g., milk, sugar) to a beverage object is a use case.
• A Beverage class with decorators like MilkDecorator extends functionality.

Behavioral Patterns

• Manage communication and responsibilities between objects.

Publish-Subscribe Pattern

• Publishers send messages to subscribers via a broker, notifying them of events.
• Publisher p1 sends "hello s1" on topic "A"; subscribers s1 and s2 (subscribed to "A") receive it.
• p1.pub("Italian") notifies subscribers to the default topic if no topic is specified.
• pub() uses a string topic, Subscriber uses a list of topics, allowing multiple subscriptions (e.g., ['A', 'B']).
• Secure channels and subscriptions are design considerations.
• Message ordering issues (priority/network delays) is a design consideration.
• Handling malformed messages or sender failures (e.g., repeated messages) is a design consideration.
• Message lifetime limits (discard if unprocessed) is a design consideration.

Modular Design with Message Broker

• Subscribers register/deregister for specific messages.
• Publishers broadcast synchronously or asynchronously.
• The Publisher sends messages via Broker.
• The Subscriber receives messages matching its topics.
• The Broker routes messages to subscribed objects.
• Microsoft Azure’s publisher-subscriber pattern is a reference.

Key Takeaways

• Software architecture is a series of decisions balancing quality attributes and tradeoffs.
• Architectural styles (e.g., Client-Server, Layered, MVC) are templates for system design.
• Design patterns (e.g., Singleton, Decorator, Publish-Subscribe) provide reusable solutions for maintainable code.
• Many styles and patterns are available and often combined in complex systems.